Updated 2014-06-04 07:57:24 by oehhar

Tcl_NotifyChannel is used by a channel driver to inform the Tcl framework that a fileevent is firering.

Official documentation: http://www.tcl.tk/man/tcl8.6/TclLib/CrtChannel.htm

HaO 2014-06-04 I created this page to document issues and design points I had with this command within the rewrite of the Windows socket driver. Thanks to DGP for discussions on this on the chat.

  socket -async connect failed which should be reported to a readable and writable event

HaO 2014-06-04: Within the socket driver, an async connect socket -async failed. This may happen:

  • Within the event queue
  • As a side effect of other commands touching the driver like fconfigure

How Tcl_NotifyChannel may be called:

1.Directly at the position where the fail arises.

This has the following issues:

  • The man page [1] does not recomment this to give other notifications a fair chance
  • One call is not enough: If there is a pending flush, a writable notification may be eaten by the Tcl framework and there is no call to the user function.
  • If the issue is not fixed (and a failed async connect is not fixable), the call must be repeated until the socket is closed.

2.By the event queue.

The upper issues are solved if Tcl_NotifyChannel is called within the event queue. The registered event source procedures (Tcl_CreateEventSource(SocketSetupProc, SocketCheckProc, NULL)) should do this:

  • The need to call Tcl_NotifyChannel should be saved in a driver internal flag variable
  • SocketSetupProc should stop blocking if flag set
  • SocketCheckProc should queue an event if flag set
  • SocketEventProc should finally call Tcl_NotifyChannel

Implemented by fossil commit [2]

See also Ticket ac661a684d and socket -async