[Patches] [ python-Patches-909005 ] asyncore fixes and improvements

[SourceForge.net]

Patches item #909005, was opened at 2004-03-03 08:07
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909005&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexey Klimkin (klimkin)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore fixes and improvements

Initial Comment:
Minor:
* 0/1 for boolean values replaced with False/True.
* (887279) Added handling of POLLPRI as POLLIN.
POLLERR, POLLHUP,
POLLNVAL are handled as exception event.
handle_expt_event gets recent
error from self.socket object and raises socket.error.
* Default readable()/writable() returns False.
* Added "map" parameter for file_dispatcher.
* file_wrapper: removed "return" in close(), recv/read
and send/write
swapped because of their nature.
* mac code for writable() removed. Manual for accept()
on mac is similar
to the one on linux.
* Repeating exception changed from "raise socket.error,
why" to raise.
* Added connected/accepting/addr reset on close().
Initialization of
variables moved to __init__.
* close_all() now calls close for dispatcher object,
EBADF treated
as already closed socket/file.
* Added channel id to "unhandled..." messages.

Bugs:
* Fixed bug (654766,889153): client never gets
connected, nor errored.
Connecting client gets writable event from select(),
however, some client may want always be non writable.
Such client may
never get connected. The fix adds _readable() - always
True for
accepting and always False for connecting socket; and
_writable() -
always False for accepting and always True for
connecting socket.
This implies, that listening dispatcher's readable()
and writable()
will never be called. ("man accept" and "man connect"
for non-blocking
sockets).
* Fixed bug: error handling after accept().
It's said, that accept can return EWOULDBLOCK even for
readable socket.
This mean, that even after handle_accept(),
dispatcher's accept() still
raise EWOULDBLOCK. New code does accept() itself and
stores accepted
socket in self.__pending_accept. If there was
socket.error, it's treated
as EWOULDBLOCK. dispatcher's accept returns
self.__pending_accept and
resets it to None.

Features:
* Added pending_read() and pending_write(). The
functions helps to use
dispatcher over non socket objects with buffering
capabilities. In original
dispatcher, if socket makes buffered read and some data
is in buffer, entering
asyncore.poll() doesn't finishes, since there is no
data in real file/socket.
This feature allow to use SSL socket, since the socket
reads data by 16k chunks.


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

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-03-21 14:48

Message:
Logged In: YES 
user_id=11375

The many number of changes in this patch make it difficult to 
figure out which changes fix which problem.  I've created a new 
directory in CVS, nondist/sandbox/asyncore, that contains copies of 
the module with these patches applied, and will work on applying 
changes to the copy in dist/src.

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

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-17 02:15

Message:
Logged In: YES 
user_id=410460

Sorry, unfortunately I have lost old patch file. I have
atached new one.
In addition to fixes, listed above, the patch includes:

1. Fix for operating on uninitialized socket. self.socket
now initializes with _closed_socket(), so any operation
throws EBADF.
2. Added class idispatcher - base class for dispatcher. The
purpose of this class is to allow simple replacement of
media(dispatcher interface) in classes, derived from
dispatcher class. This is based on 'object'.

I have also attached asynchat.diff - example for new-style
dispatcher. Old asynchat works as well.


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

Comment By: Wummel (calvin)
Date: 2004-03-11 10:49

Message:
Logged In: YES 
user_id=9205

There is no file attached! You have to click on the checkbox
next to the upload filename. This is a Sourceforge annoyance :(

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=909005&group_id=5470