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

[Adam Olsen]

On 9/9/06, Nick Maclaren <nmm1 at cus.cam.ac.uk> wrote:
> I can't honestly promise to put any time into this in the forseeable
> future, but will try (sometime).  If anyone wants to tackle this,
> please ask me for comments/help/etc.

It took me a while to realize just what was wrong with my proposal,
but I did, and it led me to a new proposal.  I'd appreciate if you
could point out any holes in it.  First though, for the benefit of
those reading, I'll try to explain the (multiple!) reasons why mine
fails.

First, sig_atomic_t essentially promises that the compiler will behave
atomically and the CPU it's ran on will behave locally atomic.  It
does not claim to make writes visible to other CPUs in an atomic way,
and thus you could have different bytes show up at different times.
The x86 architecture uses a very simple scheme and won't do this
(unless the compiler itself does), but other architectures will.

Second, the start of a write call may be delayed a very long time.
This means that a fd may not be written to for hours until after the
signal started.  We can't release any fd's used for such a purpose, or
else risk random writing to them if they get reused later..

Third, it doesn't resolve the existing problems.  If I'm going to fix
signals I should fix ALL of signals. :)

Now on to my new proposal.  I do still use write().  If you can't
accept that I think we should rip signals out entirely, just let them
kill the process.  Not a reliable feature of any OS.

We create a single pipe and use it for all signals.  We never release
it, instead letting the OS do it when the process gets cleaned up.  We
write the signal number to it as a byte (assuming there's at most 256
unique signals).

This much would allow a GUI's poll loop to wake up when there is a
signal, and give control back to the python main loop, which could
then read off the signals and queue up their handler functions.

The only problem is when there is no GUI poll loop.  We don't want
python to have to poll the fd, we'd rather it just check a variable.
Is it possible to set/clear a flag in a sufficiently portable
(reentrant-safe, non-blocking, thread-safe) fashion?

-- 
Adam Olsen, aka Rhamphoryncus