Re: [TCLCORE] Having problem with socket channel handler in 8.6

[Brian G. <bri...@ea...>]

On Aug 7, 2015, at 5:14 PM, Alexandre Ferrieux <ale...@gm...<mailto:ale...@gm...>> wrote:


On Sat, Aug 8, 2015 at 1:49 AM, Alexandre Ferrieux <ale...@gm...<mailto:ale...@gm...>> wrote:
So, in reverse, adding the UpdateInterest call as you did (or going back before the offending commit), allows a mere TCL_FILE_EVENTS to work, despite all we've just seen about synthetic events ? How come ?

One way this could happen, is that in the "fixed" situation, in your workflow, enough data (ABC) are ready on the wire so that:

  - the fd is reported as hot by select(), inducing the code to read(AB), consuming A  and leaving B in the input buffer.

  - your extra call to UpdateInterest forcibly reinjects fd in the select mask (although the input buffer is not empty)

  - since C is still unread, select() reports the fd again, but the higher-level IO code consumes only B from the buffer.

IOW, your handler keeps being called on TCL_FILE_EVENTS alone thanks to an "always hot" socket, but this is accidental and out of sync with the real synthetic events (presence of B).

If this is true, I'd suspect the workflow could be modified to exhibit a deadlock, both in the fixed and pre-commit code.
Does that make sense ?

I can imagine that happing, but's it's not what I see in this specific case.  The RPC code does a minimum of 2 calls to Tcl_Read().  I'm seeing the fd disabled after the first read, and not re-enabled after the second read which exhausted the buffer.  The socket write from the other process is happening *after* the reading process returns to the even loop to wait for the response.  It's broken, and the timer is just a false start that kicks the fd back into gear.

-Brian