woodcock@mentor.cc.purdue.edu (Bruce Sterling Woodcock) (06/17/91)
The subject basically says it all. I'm programming on a Sequent Symmetry
using Dynix V3.0.12 which, unfortunately, doesn't support the SV_INTERRUPT
flag. Most systems after 4.2BSD have it. To quote a 4.3BSD manual page:
If a caught signal occurs during certain system calls, the
call is normally restarted. The call can be forced to ter-
minate prematurely with an EINTR error return by setting the
SV_INTERRUPT bit in the flags for that signal. [...]
Currently I'm trying to port a piece of software which uses SV_INTERRUPT,
but it is still not working correctly. The code uses it to wait for a
SIGCHLD, wait for the handler to execute, and then return. However, I'm
having little success getting the code to do this properly without
SV_INTERRUPT. What I want to know is if anyone can provide a routine to
simulate the behavoir of SV_INTERRUPT, or how to work around it.
Any help is appreciated.
Bruce
--
------------------------ woodcock@mentor.cc.purdue.edu ------------------------
Yes. We fuck. Often, and with great enjoyment of the act. We aren't married,
we use birth control, we use interesting little toys on occasion. We moan like
beasts in heat. Life is *great*. -- Garrett, ref. to Tif, on alt.brother-jed.brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (06/17/91)
In article <13619@mentor.cc.purdue.edu> woodcock@mentor.cc.purdue.edu (Bruce Sterling Woodcock) writes: > The subject basically says it all. I'm programming on a Sequent Symmetry > using Dynix V3.0.12 which, unfortunately, doesn't support the SV_INTERRUPT > flag. Most systems after 4.2BSD have it. To quote a 4.3BSD manual page: One of BSD 4.2's biggest failures was forcing system calls to restart; there are just too many applications where EINTR can't be ignored. Your best bet is to use non-blocking I/O with select(). To force select() to terminate, have it check readability on an empty pipe; inside the signal handler, write a byte to the pipe, and read it back after the select(). (If you're worried about the possibility of receiving a few thousand signals before the pipe is read, keep a global flag which says whether the pipe is empty or not. Don't write unless the pipe is empty. Clear the flag when you read the pipe. Make sure to set sv_mask so that you don't have two signal handlers running at once.) If all you want to do is wait for a signal to arrive: Create a pipe. Set a flag to 0. Read one byte from the pipe; this will block. Inside the signal handler, if the flag is 0, set it to 1 and write one byte to the pipe. Once the byte has been read, close the pipe and continue. ---Dan
gwyn@smoke.brl.mil (Doug Gwyn) (06/17/91)
In article <11847.Jun1621.03.3791@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <13619@mentor.cc.purdue.edu> woodcock@mentor.cc.purdue.edu (Bruce Sterling Woodcock) writes: >> The subject basically says it all. I'm programming on a Sequent Symmetry >> using Dynix V3.0.12 which, unfortunately, doesn't support the SV_INTERRUPT >> flag. Most systems after 4.2BSD have it. To quote a 4.3BSD manual page: >One of BSD 4.2's biggest failures was forcing system calls to restart; >there are just too many applications where EINTR can't be ignored. I missed the start of this discussion, but it may be worth pointing out that my "BRL UNIX System V emulation for 4.2BSD" solved this problem by an amazing kludge, which I could have sworn that the Dynix System V environment picked up, that recovers the pre-4.2BSD behavior for interrupted "slow I/O" system calls. If Bruce would like to try it, he can drop me a note (Gwyn@BRL.MIL) and I'll send my signal() emulation that implements this kludge.