> 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
^^^^^
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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4