[Ecls-list] CVS HEAD threads and signal handling

[Juan Jose Garcia-Ripoll]

On Mon, Oct 19, 2009 at 1:10 AM, Matthew Mondor
<mm_lists at pulsar-zone.net> wrote:
> Note that SIGTERM causes ECL to exit as usual, even when it's stuck in
> that loop.  It's possible that the occurance of SIGSEGV happens because
> of a bug in the SIGINT handler code, I've not looked at the source of
> the handlers lately.  Also, you said that a new thread should be
> created at that point but the segfault seems to occur before this
> happens.

I think I more or less know what is happening. The problem is that
some thread is actually getting SIGINT. This should not happen. This
signal is blocked from all threads, and the SIGINT and some other
asynchronous signals are being pulled with sigwait(). I wonder why
this is not the case here.

>> I see this is needed when the user is blocking input in a way such
>> that the debugger can not create a toplevel. Maybe this is what is
>> happening in your case, but it something we have to consider for the
>> future.
>
> That's possible.  In this case, as expected read(2) is interrupted by
> the SIGINT signal and returns error (-1) with errno set to EINTR.  A
> single threaded C application would have the choice to supply a SIGINT
> handler and restart the read(2) syscall, or to tell the signal system
> to automatically restart syscalls (i.e. SA_RESTART bit in sigaction(2)
> man page).

The problem is that this will not always be the case. SA_RESTART is
indeed a standard flag by the OpenGroup so all unices nowadays do
implement it
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04

But my fear is that this is not always going to work. Take for
instance a copy of ECL that uses ecl-readline or some similar
software. This software disables the handling of Ctrl-C from the input
stream. That means Ctrl-C no longer generates a SIGINT signal, but is
interpreted as a character. Then our program waits for input, but gets
a SIGINT. Is the signal handling thread going to be able to gather the
console? The thread which is reading will for sure not notice it. It
only _may_ happen that the suspension signal that is issued by the
interrupting thread will interrupt the call to read(). If this is the
case, then we will indeed grab the console.

I am just somehow conjecturing and talking from what seems to be
happening with current code: it just works. However, even our approach
may be too invasive for some people's purposes and that is why we
should somehow provide other handlers.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com