[erlang-questions] Signal handling (TERM, INT etc)

[Michael FIG]

Hi,

----- "Johnny Billquist" <bqt@REDACTED> wrote:
> Tony Finch wrote:
> > On Mon, 7 Jul 2008, Johnny Billquist wrote:
> >> Tony Finch wrote:
> >>> On Tue, 1 Jul 2008, Claes Wikström wrote:
> >>>> 1. Have a socket setup from the driver to the beam (over loopback)
> >>>> 2. in the sighandler write some data on the socket.
> >>> Some of my friends recommend this technique for C programs too, so
> >>> that it becomes possible to select() for signals in the same way
> >>> as other events.
> >> Why not check for EINTR as the possible reason for -1 as returned
> >> from select()? Even if you have a signal handler, the select() will
> >> return -1 when a signal occurs.
> > 
> > Which signal?
> 
> Any signal.
> You'll have to write some other code to help figure out exactly which
> signal occured.

I think that's the point Tony was trying to make: "some other code" is simply writing the signal's number as a byte into the pipe, so that when you select and read, you can get the signal number.  That way, you can cope with a flurry of signals before they start getting lost.  If you haven't actually tried to write that "some other code", you probably don't know that it's impossible to get working reliably.

That's because your idea does not solve the inherent race condition.  What if the signal arrives while the code is doing something other than select(2) (i.e. processing the results of a prior select)?

See http://cr.yp.to/docs/selfpipe.html for the history of the "self-pipe trick".

-- 
Michael FIG <fig@REDACTED>, PMP
MarkeTel Multi-Line Dialing Systems, Ltd.
Phone: (306) 359-6893 ext. 528