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

Guido van Rossum guido@python.org
Fri, 22 Mar 2002 13:05:28 -0500

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 ^^^^^ I presume you mean 2.1.1? From the CVS log it looks like this has also been "fixed" in 2.1.2; the comment says "select not defensive. check for EINTR and make sure it's handled painlessly."

(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.

Sigh. You can't win. One user specifically wants to continue on EINTR (SF bug 453099 which caused Jeremy to create rev 1.25), another specifically wants it to propagate exception.

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?

I think if Carl (who submitted 528295) had created a signal handler that raised an exception (rather than simply return), that would probably have had the desired effect -- but I'm not 100% sure. If it works, it has the added advantage of working with earlier versions of Python too. I'd like to hear if this workaround works. Carl?

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?

I think a way to tell asyncore to exit its loop on the next iteration is still a good idea, but as it's a feature, I don't think it should be added to any revision before 2.3.

--Guido van Rossum (home page: http://www.python.org/~guido/)