[Stackless] Reconnection problem with stacklesssocket

stackless.nst at internike.com stackless.nst at internike.com
Wed Aug 11 09:34:17 CEST 2010

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.



PS:  Below is the project I'm working on. I imposed Stackless everywhere 
on the server-side.
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,<stackless.nst at internike.com>  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
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20100811/129ef143/attachment.html>

More information about the Stackless mailing list