[Python-Dev] Re: asyncore 2.1.1/2.2 incompatibility (original) (raw)
Andrew Kuchling akuchlin@mems-exchange.org
Fri, 22 Mar 2002 13:20:53 -0500
- Previous message: [Python-Dev] asyncore 2.1.1/2.2 incompatibility
- Next message: [Python-Dev] Re: asyncore 2.1.1/2.2 incompatibility
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Mar 22, 2002 at 01:05:28PM -0500, Guido van Rossum wrote:
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
2.1.1 is correct; typo on my part.
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?
Trying it, it looks like it does, and a quick glance at ceval.c agrees. The docs for libsignal don't mention anything about what happens when you raise an exception in a signal handler, though, and perhaps they should.
To sum up, it looks like this isn't a bug, and the test program should be raising a RereadConfiguration exception instead of relying on details of asyncore's loop. That also means asyncore doesn't need a way to be told to exit its loop, since raising an exception does the job nicely and Pythonically.
--amk (www.amk.ca) One has no wish to be devoured by alien monstrosities, even in the cause of political progress. -- One of the Tribunal, in "Carnival of Monsters"
- Previous message: [Python-Dev] asyncore 2.1.1/2.2 incompatibility
- Next message: [Python-Dev] Re: asyncore 2.1.1/2.2 incompatibility
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]