[Ecls-list] Threads and signal masks (Was: Special symbols ... locking or thread-local bindings)

[Matthew Mondor]

On Mon, 1 Aug 2011 20:50:29 +0200
Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> wrote:

> So it seems we are pretty safe.

Surprising how thread-friendly Lisp can be, even if the standard didn't
have a word on it, largely because of the way dynamic scope works.
Thanks for your time in helping with the audit.

The signal and debugger handling seem to remain tricky parts:

BTW, is there a facility already present in ECL so that I can in the
top-level decide which unix signal to ignore (a-la sigaction(2)
SIG_IGN), and block/unblock it on a per-thread basis (i.e. a-la
pthread_sigmask(3))?  Or must my code use inline C as necessary to do
this?  I guess that such code would have no relevance on non-POSIX OSs
though...

The problem for instance is in a test multithreaded server where
SIGPIPE generated from child threads can often be handled properly in
those threads, but the signal occasionally also is caught by other
unrelated threads (POSIX signals may interrupt any thread in the
process which doesn't block it), such as SWANK's, while it shouldn't.
Example code is there:
http://cvs.pulsar-zone.net/cgi-bin/cvsweb.cgi/mmondor/mmsoftware/cl/test/ecl-server2.lisp?rev=1.16;content-type=text%2Fplain

I looked a bit at the related code but didn't see an obvious facility
for user code to use so far.  Since I do not control the top-level of
SWANK, it'd require SWANK changes to ignore such exceptions.  Actually,
even if ECL provided the necessary facilities, unless they can be
applied from ~/.eclrc before launching SWANK, it would still need
modifications.

In this particular case, of course it'd be possible to use
SOCKET-SEND instead with a MSG_NOSIGNAL flag, and/or use polling, but
this example illustrates well the issue as-is.

Thanks,
-- 
Matt