AAron@sun.soe.clarkson.edu (02/27/91)
I have been playing around with the code posted, by Todd Marriman, that sends various esc sequences to the terminal and waits for response... and the code should kick out of the read(2V) when the alarm(3V) goes off. This is a good idea! but... I have inserted debugging lines, and determined that the execution is hanging in the read(2V), even after the alarm(3V) goes off, and it DOES go off (I had another line in the signal(3F)'s function) !!! Even after the SIGALRM I am stuck in the read(2V) !! AAAaaaarrgh! (Can you tell I have been fiddling with it a while?) Any idea why I am having problems? Thanks for getting me this far guys, AAron@sun.soe.clarkson.edu ( BTW, I don't care if you don't think this topic belongs in this group, you can just tell me where to go :-) )
gwyn@smoke.brl.mil (Doug Gwyn) (02/28/91)
In article <9102270422.AA01656@sun.soe.clarkson.edu> AAron@sun.soe.clarkson.edu writes: >and the code should kick out of the read(2V) when the alarm(3V) goes off. >Even after the SIGALRM I am stuck in the read(2V) !! AAAaaaarrgh! Sounds to me like you've been bitten by another "Berkeley Better Idea". With 4.2BSD, "slow" system calls such as reads from terminals always get restarted by the kernel when the interrupt handler resumes. I've published a really horrible user-mode hack for working around that behavior (in the signal() implementation for my System V emulation). 4.3BSD provided official support for overriding that behavior; one sets the SV_INTERRUPT bit in the sv_flags member of the structure passed to the sigvec() system call that plants the interrupt handler (in place of the usual signal() call).