| msg38255 - (view) |
Author: Hyeshik Chang (hyeshik.chang) *  |
Date: 2001-11-30 11:14 |
| fix: asyncore of 2.2b2+ fails to initialize when passed 'sock' is listening. extension(or bugfix?): more flexible handling own map |
|
|
| msg38256 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2001-12-02 11:03 |
| Logged In: YES user_id=21627 On the ENOTCONN error: Shouldn't self.accepting get set if the socket is listening? But then, the socket may not be even listening? On passing maps: Can you please explain why you use self.map if it is None? I had expected that you use socket_map in this case. |
|
|
| msg38257 - (view) |
Author: Hyeshik Chang (hyeshik.chang) * |
Date: 2001-12-04 04:14 |
| Logged In: YES user_id=55188 On the ENOTCONN error: the error will be raised only if 'sock' was bound outside. (even if self.accepting get set) but using out-bound socket is unavoidable for some server models. and I and some co-workers are using it. How about this way instead of previous patch? if not self.accepting: self.addr = sock.getpeername() On passing maps: some part of asyncore supports using own socket map. (__init__, add_channel, del_channel), but when __init__ registers socket into map which passed by argument, asyncore can't del_channel from own map and it will raises KeyError because asyncore.socket_map doesn't have such fileno. And, current version of asynchat doesn't support to use another maps. |
|
|
| msg38258 - (view) |
Author: Hyeshik Chang (hyeshik.chang) * |
Date: 2001-12-05 05:09 |
| Logged In: YES user_id=55188 Oops! sorry. It was a mistake. changed to corrected patch. |
|
|
| msg38259 - (view) |
Author: Jeremy Hylton (jhylton)  |
Date: 2001-12-13 19:09 |
| Logged In: YES user_id=31392 I'm not comfortable making changes like this with only the release candidate for testing. I think we should postpone until 2.3. |
|
|
| msg38260 - (view) |
Author: Hyeshik Chang (hyeshik.chang) * |
Date: 2001-12-14 04:39 |
| Logged In: YES user_id=55188 But, failure of sock.getpeername() is fatal for me. It interrupts initializing dispatcher class on programs which runs perfectly on all of past versions of Python. Without this patch, difference between 1.19 and 1.20 of asyncore.py must be rollbacked. (It is not important feature but fancy for __repr__) |
|
|
| msg38261 - (view) |
Author: Jeremy Hylton (jhylton) |
Date: 2001-12-14 15:14 |
| Logged In: YES user_id=31392 I see. It was hard to tell what was bug and what was feature. It does sound like you've identified a bug introduced during 2.2 development. I'll see if it's not too late. |
|
|
| msg38262 - (view) |
Author: Jeremy Hylton (jhylton) |
Date: 2001-12-14 15:21 |
| Logged In: YES user_id=31392 The dispatcher constructor sets connected to 1 when you pass it a socket. This suggests to me that the contract is that you only pass a connected socket to dispatcher. Is this what you're doing? If not, perhaps you need to create a subclass of dispatcher that behaves appropriately for non-connected sockets. |
|
|
| msg38263 - (view) |
Author: Hyeshik Chang (hyeshik.chang) * |
Date: 2001-12-14 16:25 |
| Logged In: YES user_id=55188 Hmm. thanks for your appreciation. ;) I'm using this way for non-connected sockets. class asyncore_accepting_mixin: def __init__(self, sock=None, map=None): if map is not None: self.map = map asyncore.dispatcher.__init__(self, sock, map) self.connected = 0 self.accepting = 1 I call asyncore.dispatcher.__init__ for adapting any version of asyncore. I thought this way: def __init__(.... of subclass or mixin.. try: asyncore.dispatcher.__init__(self, sock, map) except socket.error, why: if why[0] != ENOTCONN: raise socket.error, why but, this can be reasonable only if sock.getpeername() is on last line of __init__. So, subclass can't use dispatch.__init__ clearly on this condition. Anyway, thanks for your help and commit. ;) |
|
|
| msg38264 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-11-22 08:26 |
| Logged In: YES user_id=21627 Is this patch still needed? If yes, can someone provide a test case of an example that breaks without this patch but works with the patch? |
|
|
| msg38265 - (view) |
Author: Hyeshik Chang (hyeshik.chang) * |
Date: 2002-11-22 08:51 |
| Logged In: YES user_id=55188 No. All problems are resolved right after 2.2a3. Thank you! |
|
|