<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<small>Hi Richard,<br>
<br>
thank you for your reply.<br>
<br>
>From what I could see meanwhile, your intuition is correct: it has to
do with my setblocking call.<br>
I discovered that when I remove it (or set to 1 or set a timeout
value), everything is fine again.<br>
<br>
Furthermore, from what i saw, it looks like stacklesssocket has nothing
to do with it (sorry for being in the wrong ML afterall), <br>
but it's the underlying asyncore that seem to expect blocking sockets
only.<br>
<br>
In other words, you need to be in blocking mode to avoid blocking... ;-)<br>
<br>
BTW: I added a test inside stacklesssocket, to check the existence of
the 'connectChannel' in the method 'handle_connect' <br>
, before the "self.connectChannel.send(None)"</small><small>. It avoids
clashing when closing too quickly after connect.<br>
<br>
<br>
cheers,<br>
<br>
Nike<br>
<br>
<br>
PS: Below</small><small> is the project I'm working on. I imposed
Stackless</small><small> everywhere on the server-side.<br>
</small><small><a class="moz-txt-link-freetext" href="http://www.guardian.co.uk/world/2010/aug/06/eu-parliament-role-playing-game-online">http://www.guardian.co.uk/world/2010/aug/06/eu-parliament-role-playing-game-online</a></small><br>
<small>It is of course very small compared to Eve, but I thought you
might be happy to know :-)<br>
<br>
<br>
<br>
</small>On 2010-08-11 02:18, Richard Tew wrote:
<blockquote
cite="mid:AANLkTimfmCeONJ72wq_PRvoE4EHdVgbNR7K761DQXQow@mail.gmail.com"
type="cite">
<pre wrap="">On Tue, Aug 10, 2010 at 11:48 PM, <a
class="moz-txt-link-rfc2396E" href="mailto:stackless.nst@internike.com"><stackless.nst@internike.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I seem to have a problem while trying to reconnect to a (stackless) socket,
after a first connection failure.

In fact, when a first connect fails, it seems that the second will always
block forever (no matter if that one should fail or succeed).

Did I miss something ?
</pre>
</blockquote>
<pre wrap="">I've written scripts that do multiple connects before and they worked
fine -- take for example the unit tests at the bottom of the
stacklessocket.py file.

I imagine that something custom to do with your code is causing the
problem. Perhaps your stackless_addins is doing something hinky.
Perhaps, but unlikely, the setblocking call you are doing for some
unknown reason is having a side-effect.

Your best bet is to start adding print statements. Ensure that the
socket that you have connected to the second time is in the asyncore
map underlying stackless socket. Ensure that poll is being called,
and that the stacklesssocket manager that drives the asynchronous IO
has not exited. Etc.