Issue528295
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2002-03-11 00:34 by cnobile, last changed 2022-04-10 16:05 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
testSockets.py | cnobile, 2002-03-21 03:47 | Server to show problem with asyncore.py. |
Messages (8) | |||
---|---|---|---|
msg9622 - (view) | Author: Carl J. Nobile (cnobile) | Date: 2002-03-11 00:34 | |
I'm getting an unhandled write event on a handle_accept callback in asyncore.dispatch. This worked fine in python-2.1.1, but now seems to be broken in python-2.2. This happens when I send a SIGHUP to reread my config file. The signal lets me break out of the asyncore.loop() to reread the configuration and restart the server. The self.accept() method returns a TypeNone instead of the expected tuple when it is called in handle_accept. I've written a database key server which is a fairly large package and is dependent on a few other packages, so sending the code would not be too easy. If I can duplicate the problem in a few lines of code I will send it along at a later date. Thanks for your attention. Carl |
|||
msg9623 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2002-03-14 23:24 | |
Logged In: YES user_id=11375 Looking at the implementation of accept() in asyncore.py, it will return None when the socket is in non-blocking mode and the accept() would block. There's really nothing else accept() could return in this case, so you'll probably have to write your code to handle this case. |
|||
msg9624 - (view) | Author: Carl J. Nobile (cnobile) | Date: 2002-03-15 02:52 | |
Logged In: YES user_id=482117 My question then is why didn't it do this when I ran my app with python 2.1.1. Something has changed in 2.2 and I don't think it was asyncore, I do know some work was done to the low level socket and select modules so they could handle IPV6. I understand why the None is being returned, but an accept shouldn't even be called on a write event coming from a select or poll. |
|||
msg9625 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2002-03-16 20:36 | |
Logged In: YES user_id=11375 The asyncore.py in 2.1.1 seems to be revision 1.10 of the file; it's rev. 1.28 in 2.2 and is now at 1.30, so there have been a number of changes to asyncore, though none seem relevant. Did you try your code on 2.2 with the 2.1.1 asyncore? That would let us figure out if it's due to a change in asyncore or the underlying socket or select module. (Actually, another thing to check is whether the select or the poll module is being used; maybe that changed for you between 2.1.1 and 2.2.) |
|||
msg9626 - (view) | Author: Carl J. Nobile (cnobile) | Date: 2002-03-21 03:47 | |
Logged In: YES user_id=482117 Okay, The version of asyncore.py from 2.1.1 when put into the 2.2 release solves the problem, so the bug seems to be in asyncore.py. I have cobbled together a server that displays the same error and am including it here. When run in 2.1.1 it works fine, reloading the config (just a print) with a kill -1 pid and terminating with a kill pid. Carl |
|||
msg9627 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2002-03-22 17:24 | |
Logged In: YES user_id=11375 Revision 1.25 of asyncore.py is responsible. It catches EINTR and silently swallows the error, so sending signals to the process now doesn't cause it to exit asyncore's loop() at all. I don't see any unhandled write event at all. I'm not sure what to do here, and will take it up on python-dev. |
|||
msg9628 - (view) | Author: Brett Cannon (brett.cannon) * | Date: 2003-05-17 01:34 | |
Logged In: YES user_id=357491 Was this ever brought up or resolved on python-dev like Andrew planned? |
|||
msg9629 - (view) | Author: A.M. Kuchling (akuchling) * | Date: 2003-10-21 13:04 | |
Logged In: YES user_id=11375 See the thread starting at http://mail.python. org/pipermail/python-dev/2002-March/021631.html . From that thread, the consensus was that an exception should be raised. I'll close this bug. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:05:05 | admin | set | github: 36238 |
2002-03-11 00:34:37 | cnobile | create |