[Python-Dev] asyncore 2.1.1/2.2 incompatibility (original) (raw)

Andrew Kuchling akuchlin@mems-exchange.org
Fri, 22 Mar 2002 12:47:19 -0500

[Crossposted to python-dev and the Medusa mailing list, and CC'ed to the bug reporter; watch your followups!]

Bug #528295 (http://www.python.org/sf/528295) reports a difference in asyncore between 2.1.1 and 2.2. The test program attached to that bug report installs a signal handler so 'kill -HUP ' causes the program to re-read its configuration file. This works in 2.2.1 (asyncore rev. 1.10), but doesn't in 2.2 (rev. 1.30).

Revision 1.25, made to fix http://www.python.org/sf/453099, is what breaks it; as of that revision, asyncore's poll() functions catch the EINTR error and quietly go around asyncore's main loop. Before that change, the EINTR exception would propagate upward, so the test program could re-read its configuration file and then call asyncore.loop() again.

So, as I see it, it's no longer possible to usefully respond to signals with asyncore in 2.2. Is that acceptable? Or is there some clever way to make 'kill -HUP' work again?

It might be a good idea to add a function to asyncore that can be called to signal that the asyncore loop should be exited; signal handlers could then call this function to force an exit. That means asyncore users will have to rewrite their code for 2.2, though. If there's agreement that this is OK, should I try to get it into 2.2.1?

--amk (www.amk.ca) It is sometimes a mistake to climb, it is always a mistake never even to make the attempt. -- Dream, in SANDMAN: "Fear of Falling"