On Tue, 2 Aug 2011 22:06:41 +0200
Juan Jose Garcia-Ripoll <[email protected]> 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

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Ecls-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecls-list

Reply via email to