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

[Johnny Billquist]

Michael FIG skrev:
> 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".

I don't think this might be the place to dive into the deep end of signal 
handling in Unix. (It is, after all, an Erlang list).
Suffice to say that I know of the potential problems.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@REDACTED             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol