classification
Title: error: (10035, 'The socket operation could not complete without blocking')
Type: behavior Stage: test needed
Components: IDLE Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: Nosy List: ajaksu2, dhanlen, ggenellina, gpolo, terry.reedy
Priority: normal Keywords: patch

Created on 2008-04-28 19:44 by dhanlen, last changed 2011-01-13 16:59 by terry.reedy. This issue is now closed.

Files
File name Uploaded Description Edit
tkinterwork.py dhanlen, 2008-04-28 19:44 GUI for backgammon, in progress
rpc.diff ggenellina, 2009-08-05 05:44 patch against trunk (untested)
Messages (10)
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) (Python triager) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2011-01-13 16:59
This can be reopened if the problem ever appears in a current issue.
History
Date User Action Args
2011-01-13 16:59:00terry.reedysetstatus: open -> closed

messages: + msg126182
resolution: out of date
nosy: terry.reedy, ggenellina, ajaksu2, gpolo, dhanlen
2010-12-31 04:45:52terry.reedysetnosy: + terry.reedy

messages: + msg124952
versions: - Python 2.6
2009-08-05 16:36:27gpolosetmessages: + msg91323
versions: + Python 3.1, Python 2.7, - Python 3.0
2009-08-05 05:44:14ggenellinasetfiles: + rpc.diff
keywords: + patch
messages: + msg91303
2009-08-05 02:48:27gpolosetmessages: + msg91299
2009-08-05 01:47:37ggenellinasetnosy: + ggenellina
messages: + msg91293
2009-08-03 18:23:07gpolosetmessages: + msg91235
2009-04-26 22:11:29ajaksu2setpriority: normal

type: behavior
versions: + Python 2.6, Python 3.0, - Python 2.5
nosy: + ajaksu2, gpolo

messages: + msg86612
stage: test needed
2008-05-11 15:12:16georg.brandlsetcomponents: + IDLE
2008-04-28 23:30:12dhanlensetmessages: + msg65945
2008-04-28 19:44:50dhanlencreate