Extension libraries, spawned threads, and the global interpreter lock (resolved)

[Damien Elmes]

Hi Folks,

Just thought I'd write and offer up the solution to this problem.

In short, the readline module was causing weird behavior when a C-c was
received in the interactive interpreter. Instead of the SIGINT handler being
called once, it appeared to be being called once for each thread. I do not know
if that is a bug or not - a non-readline enabled interpreter seems to function
correctly.

Anyway, the fix was to wrap the call to the threaded library, blocking the INT
signal, so that to library's threads inherited the blocked behavior. This also
meant I didn't have to change the threaded library, which didn't really seem
appropriate here.

The magical code is basically of the form:

  sigset_t newset;

...

  sigemptyset(&newset); 
  sigaddset(&newset, SIGINT);

  sigprocmask(SIG_BLOCK, &newset, NULL);
  osd = xosd_init(fontdesc, colour, timeout, osd_pos, offset, shadow);
  sigprocmask(SIG_UNBLOCK, &newset, NULL);

Thanks to those who jumped in and led me in the right direction.

Damien Elmes <resolve at repose.REMOVE.cx> writes:

> Michael Hudson <mwh at python.net> writes:
> 
> > Damien Elmes <resolve at repose.REMOVE.cx> writes:
> > 
> > > The problem is that the interactive interpreter installs a sigint
> > > handler, which is sort of rude for a library to remove when it's
> > > instantianted. I think the 'default' behavior for interactive use is
> > > installed once per statement anyway, so if I were to try modify the
> > > behavior, it wouldn't change this problem.
> > 
> > If the interactiuve interpreter is involved, you get to fight readline too.
> > 
> > Good luck.
> 
> Thanks :-)
> 
> > You could try using a build without readline -- painful to use, but it
> > might just help.
> 
> That stopped the segfaults from occuring - instead of three KeyboardInterrupt
> messages appearing at once, only one does. 
> 
> Does it seem likely the problem lies in the behavior of the readline module?
> I'm pretty it's just some silly oversight on my behalf, but I can't see why
> this is happening, as AFAIK, the signals should only be being directed to the
> main thread
> 
> I've done 
> 
>   PyEval_InitThreads();
> 
> in the extension module before any threads are forked, but these threads are
> created by the pthread library. I have no desire to access python functions
> from them, I just figured they may need an interpreter lock when they get a
> signal.
> 
> I'll keep on hunting. Thanks for your patience.

-- 
Damien Elmes
resolve at repose.cx