[Python-Dev] Signals, threads, blocking C functions (original) (raw)

Nick Maclaren nmm1 at cus.cam.ac.uk
Mon Sep 4 18:24:27 CEST 2006

"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 PyErrCheckSignals(), 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

More information about the Python-Dev mailing list