Interrupt handling seems broken
Innf107 opened this issue · 1 comments
Hi,
this might just be my misunderstanding of the way this library deals with interrupts, but the current behaviour seems a bit broken.
When one presses Ctrl+C
, I would expect bestline
to do some cleanup and then re-raise the interrupt for the calling function.
This is not what happens at all.
Currently, when pressing Ctrl+C
, the library seemingly does nothing, though it "eats" the next key press (meaning, the next key press seems to be ignored, but after that everything works as expected again). Only when pressing Ctrl+C
twice, the interrupt is propagated properly and errno is set to EINTR
.
After looking at the source code and seeing that there are signal handlers in place, I tried to track down the issue and I found this in bestline.c:1360
:
rc = read(fd,&c,1);
For some reason, if the program receives an interrupt during this read
call, it does not call the interrupt handler or set errno
. Instead, read
sets c
to 3
(ETX
). I'm honestly not sure what this means or if it is intended, but I was able to get the expected behaviour by simply calling the interrupt handler manually in this case.
rc = read(fd,&c,1);
if (c == 3){
bestlineOnInt(SIGINT);
}
While this works for me right now, I doubt this is a robust fix.
Am I on the right track here, or is the current behaviour intended?
Thanks in advance.
I solved the problem of interrupts upstream in the cosmopolitan repository, where it's now possible to use a duff's device event loop. https://github.com/jart/cosmopolitan/blob/master/third_party/linenoise/linenoise.c I intend to merge it into this codebase but I haven't had time yet.