[Python-Dev] asyncore 2.1.1/2.2 incompatibility

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 <pid>' 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"