Pages: 1 2
To be slightly more clear on the issue...
Given a stream returned from a listen, after a bit of handshaking:
dataavailablefor_read seems to always return false
read() blocks and work as expected, but does not return on remote disconnect (just keeps waiting)
stream.connected seems to always return true
On Tue, 14 May 2013 00:26:08 GMT, punkUser wrote:
To be slightly more clear on the issue...
Given a stream returned from a listen, after a bit of handshaking:
dataavailablefor_read seems to always return false
When you did the busy-looping, die you call yield() inside? Since dataAvailableForRead is s non-blocking function, it needs something to keep the event loop going or nothing will arrive.
read() blocks and work as expected, but does not return on remote disconnect (just keeps waiting)
stream.connected seems to always return true
If you look at the output with the highest verbosity level (--vvvv or LogLevel.trace), does it print anything about "Socket event on fd ..." or "Connection was closed"? It's in libevent2_tcp.d/onSocketEvent where the path of execution should lead to lines 531, 549 and 557 if everything goes right.
... and I've just discovered that line 561 resumes the wrong task (fixed now, could be related, but more in the case of write() instead of read()).
When you did the busy-looping, die you call
yield()inside? SincedataAvailableForReadis s non-blocking function, it needs something to keep the event loop going or nothing will arrive.
Ah yes good point. Adding yield makes the busy-wait version work.
If you look at the output with the highest verbosity level (--vvvv or
LogLevel.trace), does it print anything about "Socket event on fd ..." or "Connection was closed"? It's in libevent2_tcp.d/onSocketEventwhere the path of execution should lead to lines 531, 549 and 557 if everything goes right.
Here's the output:
Connection was closed (fd 508).
resuming corresponding task...
resume
evbuffer_read 8 bytes (fd 508)
.. got 0 bytes
yield
It does detect the connection close in libevent and follow the path that you note, but it never seems to resume the fiber that was blocked waiting... not really sure why or how to debug.
Thanks for the help so far.
evbuffer_read 8 bytes (fd 508)
.. got 0 bytes
yield
Hmm, I believe in this case it is actually waiting on a read for 8 bytes, so maybe what's going wrong is it's resuming the task and instead of throwing an exception or whatever it used to do when disconnected, it's just spinning/yielding some more in the read() even though the remote hung up?
Am 14.05.2013 23:05, schrieb punkUser:
Yeah that definitely seems to be related... if I put a "checkConnected();" inside the libevent read() loop it seems to fix it. Not sure if that's the 'right' fix though?
Sounds good. I think I may have accidentally moved thecheckConnected() call outside of the loop in a recent commit.
Pages: 1 2
