Tcl Source Code

Another trouble that arose in the recent TCLCORE thread on
socket handler bugs reported by Brian Griffin.

The Tcl_DoOneEvent() routine advertises the ability to choose
input flags to selectively process subsets of all possible events.

The flag TCL_FILE_EVENTS has a name that suggests it will
drive all the event handling needed to make async I/O work.
That is not true.

The way async I/O is actually implemented relies also on
timer events in several places.  This includes draining input
buffers and kick-starting async [chan copy] operations.

The most difficult change needed to address this appears to
be in the facilities offered by [chan create] to define so-called
reflected channels.  The [chan postevent] command offered to
signal chan events within a single thread is implemented by
a direct call to Tcl_NotifyChannel().  If instead, you wish to
have a trip through the event loop manage this (async vs sync),
the only script-level tool that appears available is the use of
a timer event established with the [after] command.

That change doesn't really address the issue here, best I can recall.
After the change, it remains true that I/O operations cannot fully function
with support of TCL_FILE_EVENTS only, and TCL_TIMER_EVENTS have to be
working too.  The shift is just in whether a reflected channel can make
a choice of synchronous [chan postevent] or use [after] to create async
operations.  After the change, [chan postevent] itself is asyncronous
by use of timer events internally created.  The need for timer events
is still there, just out of script-level control.

The other effect is to remove the ability for a synchronous use
of [chan postevent], which is at least the incompatible change of
loss of function in a public command.

Fixed in [e066e24f36f6] for issue [67a5eabbd3d1].