Very high IDLE_WAKE - Power consumption

[tcolar]

Something in tcell is causing a lot of idle wake, causing battery drain, it maybe a system event or ticker or such but I have not found the source of it as of yet.

Here is data from just running the mouse demo (it also happens with micro and other tcell apps)

[tcolar]

This is another way to see the same data:
top -stats pid,command,cpu,idlew,power -o power -d

PID    COMMAND          %CPU IDLEW POWER
34328  mouse            0.6  528   22.2 

[tcolar]

FYI, found the culprit to be the very short time out here : https://github.com/gdamore/tcell/blob/master/tscreen_bsd.go#L70

    // We wake up at the earliest of 100 msec or when data is received.
    // We need to wake up frequently to permit us to exit cleanly and
    // close file descriptors on systems like Darwin, where close does
    // cause a wakeup.  (Probably we could reasonably increase this to
    // something like 1 sec or 500 msec.)
    newtios.Cc[syscall.VMIN] = 0
    newtios.Cc[syscall.VTIME] = 1
    tios = uintptr(unsafe.Pointer(&newtios))

With a larger timeout value such as 5 seconds it behaves, but seeing your comment, not sure there is a simple workaround but I might have a look later.

[gdamore]

Yep. We have to wake up pretty often... this is a stupid bug in BSD with close() in the termios driver. Probably VTIME could be increased ... for example moving it to 5 would reduce the wake up count to 1/5th its current level, but would mean that it would take applications up to 1/2 second to exit cleanly.

Without this call, the application would hang (the read for data would block indefinitely) once the descriptor was closed.

Arguably, I could use some other notification mechanism and poll() instead -- if I have time later I'll think about this -- certainly not having to do the periodic wakeups would be attractive!

If I recall correctly, I saw this problem on MacOS, but not on other systems. I tracked it to a termios bug. I suspect the same bug may exist elsewhere, though.

[tcolar]

Yeah sounds good, I didn't notice the longer quit time but I ll check again. In any case thanks for making this, I don't miss term box.

[gdamore]

The above PR is one way to address it... but it doesn't allow for properly terminating tcell and restarting it. As a result, I'm not too thrilled with it. It might be reasonable though.

I want to think this through further too -- its likely that on some systems we don't have to dispense with the final close(), and that its only a problem for the BSD systems that have buggy termio drivers.

I'll probably write a test suite that people can run to see if their system is defective.

[gdamore]

(Basically the defect is this -- read(2) should not continue to be blocked if the file descriptor is close(2)d. The close(2) should wake the read(2), which should then return EBADF.

[tcolar]

@gdamore I tried the PR, it does somewhat fix the issue although I had to modify it a little (insert a short sleep in the loop here https://github.com/gdamore/tcell/pull/130/files#diff-8feb5118e0c0711372db5cc7647c0e01R1252 because otherwise it tend to read single bytes at a time and with terminal sequence codes already being somewhat indeterministic that causes more issues).

You mentioned using poll() before that sounds likely a better fix, any reason why you didn't go that route ? Or is it just a larger chnage that would take more time ?

Thanks.

[gdamore]

I've completely refactored the input loop and this is fixed in my test branch (inputrefactor) . Stay tuned.