| msg65928 - (view) |
Author: Don Hanlen (dhanlen) |
Date: 2008-04-28 19:44 |
| IDLE internal error in runcode() Traceback (most recent call last): File "C:\PYTHON25\lib\idlelib\rpc.py", line 235, in asyncqueue self.putmessage((seq, request)) File "C:\PYTHON25\lib\idlelib\rpc.py", line 332, in putmessage n = self.sock.send(s[:BUFSIZE]) error: (10035, 'The socket operation could not complete without blocking') Does this look familiar to anyone? I can't figure out what to do about it. Python 2.5, windoze. I get it when I execute a Tkinter op that works elsewhere. changing this (works): t = self.b.create_text( (point.baseX + 1)*self.checkerSize/2 + fudge, y + fudge, text = str(point.occupied), width = self.checkerSize) to t = self.b.create_text( (point.baseX + 1)*self.checkerSize/2 + fudge, y + fudge, text = str(point.occupied), font=("Times", str(self.checkerSize/2), "bold"), width = self.checkerSize) for example. The same code works fine elsewhere. I thought I'd ask here before I try (no clue) increasing BUFSIZE in rpc.py? I'm not crazy about tinkering with code I have no clue about.. It has been suggested that the problem is competition with IDLE for tkinter resources. -- don |
|
|
| msg65945 - (view) |
Author: Don Hanlen (dhanlen) |
Date: 2008-04-28 23:30 |
| ah, lines 284-289 (the lines in question) need indenting 4 levels. I just DL'd 2.5.2, ran the code once, no problem, 2nd time, got the usual error message. |
|
|
| msg86612 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
Date: 2009-04-26 22:11 |
| Don: any news on this? Do you still get the same error with 2.6? |
|
|
| msg91235 - (view) |
Author: Guilherme Polo (gpolo) *  |
Date: 2009-08-03 18:23 |
| Hi Don, I don't think this is an issue about idle competing for tkinter resources (or idle and tkinter competing for resources -- the other meaning I got when reading your message). From what I remember this WSAEWOULDBLOCK is just a way for Windows to tell "try to send this data again later", so this is actually related to networking and not Tkinter vs. IDLE. If someone can confirm this then it would be better to check for this specific error and ignore (pass) instead of always raising any socket.error. |
|
|
| msg91293 - (view) |
Author: Gabriel Genellina (ggenellina) |
Date: 2009-08-05 01:47 |
| AFAIK, WSAEWOULDBLOCK means that the socket is in nonblocking mode and the attempted operation could wait indefinitely to complete. But I don't understand how that could happen since a previous select() confirmed the socket is writeable... Probably the whole code block could be replaced by a single self.sock.sendall(s) call. |
|
|
| msg91299 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-08-05 02:48 |
| > AFAIK, WSAEWOULDBLOCK means that the socket is in nonblocking mode and > the attempted operation could wait indefinitely to complete. Rather pessimistic way to see it :) I've always read it as "operation cannot be completed without blocking". > But I > don't understand how that could happen since a previous select() > confirmed the socket is writeable... Richard Stevens, MSDN (http://msdn.microsoft.com/en-us/library/ms741540(VS.85).aspx) and possibly several other authors and places will tell it is possible to happen. I've always seen this being handled as "try again later". |
|
|
| msg91303 - (view) |
Author: Gabriel Genellina (ggenellina) |
Date: 2009-08-05 05:44 |
| So this patch should fix it. But I cannot fire the bug using the posted example, and there are no test cases for this module yet, so I could not test it. |
|
|
| msg91323 - (view) |
Author: Guilherme Polo (gpolo) * |
Date: 2009-08-05 16:36 |
| I just tried writing tests for it, but I don't know idlelib/rpc.py enough yet. You can see this first attempt at: http://svn.python.org/view?view=rev&revision=74320 I started trying to test rpc.RPCClient together with run.main but it seemed too high level. Then I moved to try to test rpc.SocketIO directly, but it seems I'm doing wrong things there. Most of times SocketIOTest will fail by raising ValueError which then causes the server process to finish and either cause a "Connection reset by peer", "Broken pipe" or nothing (these are on Linux, on Windows I would expect to get "An existing connection was forcibly closed by the remote host"). Sometimes it also succeeds. |
|
|
| msg124952 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2010-12-31 04:45 |
| If there is no verification that there is a bug in 2.7/3.1,2, then I think this should be closed. |
|
|
| msg126182 - (view) |
Author: Terry J. Reedy (terry.reedy) * |
Date: 2011-01-13 16:59 |
| This can be reopened if the problem ever appears in a current issue. |
|
|