[Ecls-list] Threads and signal masks

[Matthew Mondor]

On Tue, 2 Aug 2011 22:06:41 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> (ext:catch-signal ext:+sigpipe+ nil) ;; Global
> (ext:catch-signal ext:+sigpipe+ nil :local t) ;; Thread local

Thanks, I could finally play a bit with these and also read their
implementation.

For the particular case of the test server, I could use the second form
to block-mask SIGPIPE in both the parent and children threads in their
prologue.

One thing of interest is that the first form only allows to restore a
signal to the SIG_DFL state and not SIG_IGN.  In this particular case
for instance, ignoring SIGPIPE for the whole process would be nice too,
but if I use this interface to try, the process will obviously instead
exit at the first SIGPIPE occurance (the default behaviour on POSIX for
SIGPIPE is to terminate the process).

If the interface allowed :ignore :default and :catch in the first form,
this would be possible.  Yet this would make no sense in the second
form which is actually to change the mask for a thread.

Is CATCH-SIGNAL in any way currently already relied-upon by some
software?  Also, does it try to be compatible in any way with an
existing interface?  Is it expected to eventually do anything on
non-POSIX systems?

If all the answers are no, I would then propose a few changes that
would allow to better use the POSIX functionality:

(ext:posix-signal-action signo behavior)
	where BEHAVIOR could be :IGNORE :DEFAULT :CATCH
	using sigaction(2) for :IGNORE or :DEFAULT,
	letting ECL handle it and issue a condition for :CATCH

(ext:posix-signal-mask signo boolean &key (scope :global))
	where setprocmask(2) would be used for SCOPE :GLOBAL
	and pthread_sigmask(2) would be used for SCOPE :LOCAL
	An error would be signaled if :LOCAL is used in a non-MP build

Obviously, for the special cases of signals we must not allow user code
to temper with for proper ECL functionality, common sanity checking
code would be used for both to signal an error.

What do you think?

Note that if you agree, this is non-urgent; and I possibly could myself
eventually send you a diff for this interface, now that I read how the
previous interface is implemented in relation to catch.

Thanks again for your time,
-- 
Matt