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

[Nick Maclaren]

"Gustavo Carneiro" <gjcarneiro at gmail.com> wrote:
>
>   You guys are tough customers to please.  I am just trying to solve a
> problem here, not create a new one; you have to believe me.

Oh, I believe you.

Look at it this way.  You are trying to resolve the problem that your
farm is littered with cluster bombs, and your cows keep blowing their
legs off.  Your solution is effectively saying "well, let's travel
around and pick them all up then".

>   We want to get rid of timeouts.  Now my idea: add a Python API to say:
>      "dear Python, please call me when you start having pending calls,
> even if from a signal handler context, ok?"

Yes, I know.  I have been there and done that, both academically and
(observing, as a consultant) to the vendor.  And that was on a system
that was a damn sight better engineered than any of the main ones that
Python runs on today.

I have attempted to do much EASIER tasks under both Unix and (earlier)
versions of Microsoft Windows, and failed dismally because the system
wasn't up to it.

> From that point on, signals will get handled by Python, python calls
> PyGTK, PyGTK calls a special API to safely wake up the main loop even
> from a thread or signal handler, then main loop checks for signal by
> calling PyErr_CheckSignals(), it is handled by Python, and the process
> lives happily ever after, or die trying.

The first thing that will happen to that beautiful theory when it goes
out into Unix County or Microsoft City is that a gang of ugly facts
will find it and beat it into a pulp.

>  I sincerely hope my explanation was satisfactory this time.

Oh, it was last time.  It isn't that that is the problem.

> Are signal handlers guaranteed to not be interrupted by another
> signal, at least?  What about threads?

No and no.  In theory, what POSIX says about blocking threads should
be reliable; in my experience, it almost is, except under precisely the
circumstances that you most want it to work.



Look, I am agreeing that your basic design is right.  What I am saying
is that (a) you cannot make delivery reliable and abolish timeouts
and (b) that it is such a revoltingly system-dependent mess that I
would much rather Python didn't fiddle with it.

Do you know how signalling is misimplemented at the hardware level?
And that it is possible for a handler to be called with any of its
critical pointers (INCLUDING the global code and data pointers) in
undefined states?  Do you know how to program round that sort of
thing?

I can answer "yes" to all three - for my sins, which must be many and
grievous, for that to be the case :-(


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679