« first day (322 days earlier)      last day (1213 days later) » 

bakul
bakul
00:28
@ngn you should use select() if you have multiple input/output channels such as socket connections as well as console. Then you read/write in non-blocking mode and do your i/o waiting at select(). The other option is to use threads but then you have to worry about shared state.
select() or equivalent on other platforms. 
For character i/o the cbreak mode is often good enough. Then if your process hangs you can still regain control.
ngn
ngn
@bakul the question is, if select() is already waiting for input from stdin (among other file descriptors), can the application read() 1 byte specifically from stdin?
bakul
bakul
Yes
ngn
ngn
@bakul do you know if there's a way to do that in k4/q?
bakul
bakul
No idea about k4. But let me be more specific. if select() returns with fd 0 as ready, then you can read a char.
ngn
ngn
00:52
@bakul so, the problem seems to be that after a select(), k4 read()-s whatever input is available for the purposes of its repl
that prevents the application from doing its own read() with 1:: because all the data has already gone to the repl
i tried this: ."\\stty raw";1:(`:/dev/fd/0;1) (warning: be prepared to kill the q process) but got back only empty byte lists
bakul
bakul
Ideally ref to /dev/fd/0 should open a new file descriptor
Are you trying to use it like the way you read in a shell?
ngn
ngn
@bakul just trying to help @rcabaco make a terminal ui
it requires immediate feedback when a key is pressed
bakul
bakul
01:08
Hm... ideally k4 should give the lowest priority for command input so that the new fd will have a chance to read.
But often people using select() read from lowest ready fd to highest ready fd, which could explain the behavior. Ideally k4 should use round robin for all non-commands file descriptors and if none are ready it should then read from the command input

« first day (322 days earlier)      last day (1213 days later) »