[Python-Dev] Signals, threads, blocking C functions

[Jean-Paul Calderone]

On Mon, 04 Sep 2006 15:05:56 +0100, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
>"Gustavo Carneiro" <gjcarneiro at gmail.com> wrote:
>>
>> That's a very good point; I wasn't aware that child processes
>> inherited the signals mask from their parent processes.
>
>That's one of the few places where POSIX does describe what happens.
>Well, usually.  You really don't want to know what happens when you
>call something revolting, like csh or a setuid program.  This
>particular mess is why I had to write my own nohup - the new POSIX
>interfaces broke the existing one, and it remains broken today on
>almost all systems.
>
>>   I am now thinking of something along these lines:
>> typedef void (*PyPendingCallNotify)(void *user_data);
>> PyAPI_FUNC(void) Py_AddPendingCallNotify(PyPendingCallNotify callback,
>>     void *user_data);
>> PyAPI_FUNC(void) Py_RemovePendingCallNotify(PyPendingCallNotify
>>     callback, void *user_data);
>
>Why would that help?  The problems are semantic, not syntactic.
>
>Anthony Baxter isn't exaggerating the problem, despite what you may
>think from his posting.
>

Dealing with threads and signals is certainly hairy.

However, that barely has anything to do with what Gustavo is talking
about.

By the time Gustavo's proposed API springs into action, the threads
already exist and the signal is already being handled by one.  So,
let's forget about threads and signals for a moment.

The problem to be solved is that one piece of code wants to communicate
a piece of information to another piece of code.

The first piece of code is in Python itself.  The second piece of code
could be from any third-party library, and Python has no way of knowing
about it - now.

Gustavo is suggesting adding a registration API so that these third-party
libraries can tell Python that they exist and are interested in this
piece of information.

Simple, no?

PyGTK would presumably implement its pending call callback by writing a
byte to a pipe which it is also passing to poll().  This lets them handle
signals in a very timely manner without constantly waking up from poll()
to see if Python wants to do any work.

This is far from a new idea - it's basically the bog standard way of
handling this situation.  It strikes me as a very useful API to add to
Python (although at this point in the 2.5 release process, not to 2.5,
sorry Gustavo).

Jean-Paul