Hi Richard,
thank you for your reply.
From what I could see meanwhile, your intuition is correct: it has to
do with my setblocking call.
I discovered that when I remove it (or set to 1 or set a timeout value),
everything is fine again.
Furthermore, from what i saw, it looks like stacklesssocket has nothing
to do with it (sorry for being in the wrong ML afterall),
but it's the underlying asyncore that seem to expect blocking sockets only.
In other words, you need to be in blocking mode to avoid blocking... ;-)
BTW: I added a test inside stacklesssocket, to check the existence of
the 'connectChannel' in the method 'handle_connect'
, before the "self.connectChannel.send(None)". It avoids clashing when
closing too quickly after connect.
cheers,
Nike
PS: Below is the project I'm working on. I imposed Stackless everywhere
on the server-side.
http://www.guardian.co.uk/world/2010/aug/06/eu-parliament-role-playing-game-online
It is of course very small compared to Eve, but I thought you might be
happy to know :-)
On 2010-08-11 02:18, Richard Tew wrote:
On Tue, Aug 10, 2010 at 11:48 PM,<[email protected]> wrote:
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 ?
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.
Cheers,
Richard.
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless