termbox.PollEvent wait forever after reading from Stdin from tmux command

[vheon]

I don't know if this is a problem with termbox-go per se.

I have this simple program https://gist.github.com/vheon/74388c0dd68e21413eb8. If I ran this as

printf "foo\nbar\nqux" | ./simplebox

everything works fine, if I press <C-n> or <C-p> the selected line change.

if I have multiple sessions inside tmux and run

tmux list-sessions | ./simplebox

everything freeze and the only way to exit is to killall "simplebox" from another shell. I checked and the program is blocked on PollEvent.

[nsf]

Works on my machine. Also your program expects "Esc" key which is available only in termbox.InputEsc mode. Add that line after termbox init:

termbox.SetInputMode(termbox.InputEsc)

What's the shortest way to reproduce it with tmux? You're saying it hands with multiple tmux sessions, does it hang with just one session? Is there some connection to number of sessions in general? I've noticed that the program hangs if stdin is empty, i.e. if you run it without sending stdin. What tmux list-sessions returns without redirecting it to simplebox?

[nsf]

Oh, sorry. InputEsc is the default one. No need to add that line.

[vheon]

On my machine this is the output of tmux list-sessions is

jedihttp: 4 windows (created Thu May 21 11:29:37 2015) [158x43]
misc: 1 windows (created Thu May 21 11:29:38 2015) [158x43]
picker: 4 windows (created Thu May 21 11:29:38 2015) [158x43] (attached)

and it freeze. I tried with just one session and the same thing happened.

[nsf]

What about random output? Like ls ~ | ./simplebox. Does it freeze too?

[nsf]

Also what tmux -V says? Mine:

[nsf @ ~]$ tmux -V
tmux 2.0

[vheon]

I'm on 1.9a.

[nsf]

Could you try 2.0 then? Maybe it will just work, who knows.

[vheon]

Nope. It works the first time I launch it, and from the second time, nothing.

[nsf]

Can you tell me exactly how to reproduce it? This is what I do:

tmux
ls ~ | ./simplebox
# all works fine here
<C-b> <d> # detaching from session
tmux attach
ls ~ | ./simplebox
# all still works just fine

I've deleted my tmux config file just in case. I don't see any hangs.

[vheon]

That is what I did:

tmux new-session -s test1
<C-b>d
tmux new-session -s test2
ls ~ | ./simplebox
# all works fine
tmux list-session | ./simplebox
# it hangs

[vheon]

I tried without my tmux.conf and same results.

[nsf]

It's really weird. I tried to do the same what you suggested. Works fine.

[nsf]

Well, I remember there were some issues with termbox closing stdin or something like that. Try go get -u github.com/nsf/termbox-go, and then rebuild your app, maybe termbox version is out of date.

[vheon]

If it is not much trouble could you try as before but:

tmux new-session -s test1
<C-b>d
tmux new-session -s test2
ls ~ | ./simplebox
# all works fine
tmux list-session | ./simplebox
# if it works try again
tmux list-session | ./simplebox

Sometimes it works a first time and then hangs.

[nsf]

Tried 10 times or so. Works.

[nsf]

It sucks that I can't reproduce it. I guess the issue will keep hanging there.

Oh and I haven't asked what's your OS? Because I'm running it on linux and if it's a MacOSX, it changes everything. :D

[vheon]

yes, I'm on Mac

[vheon]

I should've told you sooner, sorry.

[nsf]

Yeah, could be the mac issue, because I don't have a mac and therefore it's the least tested OS when it comes to termbox-go. Yeah, it's mostly POSIX and the implementation is similar, but there could be slight differences in syscalls behaviour. Like when SIGIO is sent and what Read returns. Sadly I don't have a mac, so at this moment I can't help you. Maybe I'll eventually try to get hackintosh running in a virtualbox or something.

[vheon]

If you need some testing I could do it, just tell me what to do :) Anyway thanks for your time 👍

[syohex]

There is a same issue(peco/peco#255).
We can reproduce this issue without go(also termbox-go). peco/peco#255 (comment)

So I also think this is MacOSX kernel issue.

[nsf]

Well, I'm sure any modern OS has some proper way of doing async I/O. That's what termbox requires. The reason for this is a need to be able to do graceful shutdown. We can't just block a goroutine waiting for input, because if library user decides to quit, you can't unblock a read syscall. That's how I do it on windows (btw, haven't tested enough, not sure if it even works correctly):

https://github.com/nsf/termbox-go/blob/master/termbox_windows.go#L743-L813

Basically a similar solution to POSIX's select. Initially termbox was designed with select in mind. There was a unix pipe delivering SIGWINCH which is an object you can wait for using select call. So, similarly we can make a pipe which is used to interrupt a blocking select call. But the question is - is it the best way to do it? Is it the best way to do it on linux? on darwin?

I'm pretty sure it's all possible on all OSes. All OSes have some kind of a semaphore implementation (that is a waiting queue for threads and a way to wake them up) and some kind of a multi-object management system, be it select or WaitForMultipleObjects. Sadly I'm completely unfamiliar with darwin OS.

[syohex]

But the question is - is it the best way to do it? Is it the best way to do it on linux? on darwin?

I have no idea yet.

[nsf]

And I have no time to figure that out. When I have, I will.

[gdamore]

I believe there is an excellent chance that my fix in PR #99 will solve this. After that change is pulled, termbox-go no longer depends on or uses either SIGIO or async/IO. Please give it a whirl.