[Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event

[noreply@sourceforge.net]

Bugs item #528295, was opened at 2002-03-10 19:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl J. Nobile (cnobile)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore unhandled write event

Initial Comment:
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

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-22 12:24

Message:
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.



----------------------------------------------------------------------

Comment By: Carl J. Nobile (cnobile)
Date: 2002-03-20 22:47

Message:
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

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-16 15:36

Message:
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.)



----------------------------------------------------------------------

Comment By: Carl J. Nobile (cnobile)
Date: 2002-03-14 21:52

Message:
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.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 18:24

Message:
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.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470