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 (connect -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 [http://www.tcl.tk/man/tcl8.6/TclLib/CrtChannel.htm] 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 [https://core.tcl.tk/tcl/info/711c272f369d86d95493230c1999184a11e5a225] See also [https://core.tcl.tk/tcl/tktview?name=ac661a684d%|%Ticket ac661a684d%|%] <> <> Tcl Library