homepage

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

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.

Don: any news on this? Do you still get the same error with 2.6?

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.

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.

> 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".

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.

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.

If there is no verification that there is a bug in 2.7/3.1,2, then I think this should be closed.

This can be reopened if the problem ever appears in a current issue.