| msg67188 - (view) |
Author: Alexander Shigin (shigin) |
Date: 2008-05-22 13:23 |
| Unix select returns socket in read fd set and write fd set if nonblocking socket attempts to connect to unaviable address. asyncore should check this case by calling getsockopt with SO_ERROR optname. If return value is 0 it should call handle_connect_event, otherwise if should call handle_expt_event. Attached file prints "get exception" if asyncore can't connect to remote side, not "uncaptured python exception" Patches from Issue1736190 do not fix this case. |
|
|
| msg67189 - (view) |
Author: Alexander Shigin (shigin) |
Date: 2008-05-22 13:26 |
| Patch against r63534 fix the issue. |
|
|
| msg67196 - (view) |
Author: Alexander Shigin (shigin) |
Date: 2008-05-22 15:52 |
| Oh, I've just realised that FreeBSD is too fast. test_async_connect.py works fine on linux box, but on FreeBSD i need to change localhost to another host :( I haven't got any idea how to make a test case which work on any machine. |
|
|
| msg67306 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) *  |
Date: 2008-05-24 18:25 |
| By trying your script on Linux and Windows I notice different behaviors. On Windows handle_expt is always called. On Linux, no matter if using select or poll, handle_accept is called, then an exception is thrown at the time the data is going to be sent: Traceback (most recent call last): File "index.py", line 34, in test() File "index.py", line 31, in test asyncore.loop(use_poll=1) File "/usr/lib/python2.5/asyncore.py", line 205, in loop poll_fun(timeout, map) File "/usr/lib/python2.5/asyncore.py", line 190, in poll2 readwrite(obj, flags) File "/usr/lib/python2.5/asyncore.py", line 101, in readwrite obj.handle_error() File "/usr/lib/python2.5/asyncore.py", line 93, in readwrite obj.handle_read_event() File "/usr/lib/python2.5/asyncore.py", line 400, in handle_read_event self.handle_connect() File "index.py", line 17, in handle_connect self.send("hello world") File "/usr/lib/python2.5/asyncore.py", line 481, in send self.initiate_send() File "/usr/lib/python2.5/asyncore.py", line 468, in initiate_send num_sent = dispatcher.send(self, self.out_buffer[:512]) File "/usr/lib/python2.5/asyncore.py", line 345, in send result = self.socket.send(data) socket.error: (111, 'Connection refused') In my opinion both behaviors are wrong since neither handle_expt nor handle_connect should be called in case of a "connection refused" event. Especially handle_connect should not be called at all since no connection takes place. The correct behavior here must be identifying when such event occurs, raise the proper exception (ECONNREFUSED) and let it propagate until handle_error which will take care of it. |
|
|
| msg67308 - (view) |
Author: Alexander Shigin (shigin) |
Date: 2008-05-24 19:02 |
| Oh, fine. May be handle_error should have been called, but anyway not handle_connect. But in my mind, handle_expt is better. |
|
|
| msg69427 - (view) |
Author: Alexander Shigin (shigin) |
Date: 2008-07-08 13:27 |
| Here is a new patch against r64768 The new patch raise an exception if asynchronous connect fails. |
|
|
| msg74125 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2008-10-01 11:29 |
| This should have already been fixed in r64062. |
|
|
| msg74127 - (view) |
Author: Alexander Shigin (shigin) |
Date: 2008-10-01 12:01 |
| I've got the same error in r64768. |
|
|
| msg112704 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2010-08-03 22:06 |
| Assigning this to me. The patch looks correct, it only needs tests assuming it is possible to write a reliable test for this. |
|
|
| msg112775 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2010-08-04 09:05 |
| Fixed in r83703 (2.7), r83704 (2.6), r83705 (3.2) and r83706 (3.1). Thanks for the patch. |
|
|
| msg113707 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-08-12 21:27 |
| The fix for this was applied after 2.6.6rc1, and it wasn't approved by me. Is it critical for 2.6? Is it a regression since 2.6.5? The way I see it, we either back this out or release an rc2. There may be other reasons to release an rc2, but I need to verify that that is possible for MvL. |
|
|
| msg113709 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-08-12 21:46 |
| What date would the final release then be made? It would be best if it could be done before Aug 27. If necessary, I could also make a release on September 6 (but not any day before or after) |
|
|
| msg113710 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2010-08-12 21:50 |
| The bug is not a regression since 2.6.5; AFAICT, it was in Python "forever". I recommend to revert the checkin, and postpone fixing it to 2.7.1. |
|
|
| msg113715 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-08-12 22:46 |
| I agree w/mvl. Giampaolo, please revert this for 2.6.6. |
|
|
| msg113730 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2010-08-13 01:04 |
| The commit was made on August 04, 11:05 AM, while rc1 was released at 06:09 PM. I don't think the patch is going to introduce any problem but if you think it's the case to revert it then I'll do it. |
|
|
| msg113733 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-08-13 01:18 |
| The question isn't when it was released, but when it was tagged, and that happened at Aug 3 22:51:57 2010 UTC according to svn. Your commit was made Aug 4 08:58:38 2010 UTC. |
|
|
| msg113735 - (view) |
Author: Giampaolo Rodola' (giampaolo.rodola) * |
Date: 2010-08-13 01:31 |
| Ok, no problem. Reverted in r83969. |
|
|
| msg113857 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-08-14 00:46 |
| Just to close the loop: thanks for reverting this for 2.6.6! |
|
|