1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • Trying to fully understand the event loop

    From pd@21:1/5 to All on Wed Aug 10 12:03:40 2022
    I was reading about the event loop to understand how it's implemented in tcl, in short I've learnt the event loop relies basically in three elements: the event generator called the notifier, the event loop itself called tcl_DoOneEvent and event consumers
    which are essentially callback procs.

    As far as I understand the notifier is a kind of wrapper over system events translating them to tcl events stored in a tcl event queue. The event loop Tcl_DoOneEvent consume events from that queue calling the "subscribed" procs, you init the even loop by
    calling a special tcl command (vwait, fileevent...) indicating what proc is to be called when the right kind of event is processed in the event queue.

    If this insight is more or less accurate I understand the notifier is system dependant (different for unix o windows) and related to system facilities to track events.

    My question is how it is done?

    I mean, It's said the tcl event loop is single thread but I suppose the notifier has to run on a different thread because it must be running all the time at the same time of tcl itself to detect events when happen and feed them to the tcl event queue in
    an asynchronous way.

    Other possibility is Tcl_DoOneEvent calls the notifier as first step to feed events to the queue and then process events in the queue until some condition is verified, but this may lead to an event queue never fully consumed. And also maybe a long wait
    if notifier waits for events to come (for example in a unix select call)

    regards

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From apn@21:1/5 to All on Thu Aug 11 08:31:57 2022
    On 8/11/2022 12:33 AM, pd wrote:> I mean, It's said the tcl event loop
    is single thread but I suppose the notifier has to run on a different
    thread because it must be running all the time at the same time of tcl
    itself to detect events when happen and feed them to the tcl event
    queue in an asynchronous way.>> Other possibility is Tcl_DoOneEvent
    calls the notifier as first step to feed events to the queue and then
    process events in the queue until some condition is verified, but this
    may lead to an event queue never fully consumed. And also maybe a long
    wait if notifier waits for events to come (for example in a unix select
    call)
    Each thread running a Tcl interp has its own event queue and event loop.
    When queuing events, call Tcl_QueueEvent to add an event to the current thread's event queue or Tcl_ThreadQueueEvent to add to another thread's
    queue.

    /Ashok

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Harald Oehlmann@21:1/5 to All on Thu Aug 11 08:59:36 2022
    Am 10.08.2022 um 21:03 schrieb pd:
    I was reading about the event loop to understand how it's implemented in tcl, in short I've learnt the event loop relies basically in three elements: the event generator called the notifier, the event loop itself called tcl_DoOneEvent and event
    consumers which are essentially callback procs.

    As far as I understand the notifier is a kind of wrapper over system events translating them to tcl events stored in a tcl event queue. The event loop Tcl_DoOneEvent consume events from that queue calling the "subscribed" procs, you init the even loop
    by calling a special tcl command (vwait, fileevent...) indicating what proc is to be called when the right kind of event is processed in the event queue.

    If this insight is more or less accurate I understand the notifier is system dependant (different for unix o windows) and related to system facilities to track events.

    My question is how it is done?

    I mean, It's said the tcl event loop is single thread but I suppose the notifier has to run on a different thread because it must be running all the time at the same time of tcl itself to detect events when happen and feed them to the tcl event queue
    in an asynchronous way.

    Other possibility is Tcl_DoOneEvent calls the notifier as first step to feed events to the queue and then process events in the queue until some condition is verified, but this may lead to an event queue never fully consumed. And also maybe a long wait
    if notifier waits for events to come (for example in a unix select call)

    regards


    Well, "fully understanding" is a high demand, specially on all platforms.
    On Windows, I can say, that the event system is often used to get an
    event from the notifier thread to the TCL thread. So, you supposition is correct, that there are multiple threads. Nevertheless, the notifier
    thread must deal intenally with the fact to get the information in the
    main thread. The event system will only guarantee to get a callback, if
    there is time for an event. Within this callback, the information is
    taken from the event thread and the event is sheduled in TCL.


    Maybe, some wiki examples

    https://wiki.tcl-lang.org/page/Tcl%5FNotifyChannel

    https://wiki.tcl-lang.org/page/Tcl%5FCreateEventSource

    Enjoy,
    Harald

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From heinrichmartin@21:1/5 to Rich on Thu Aug 11 00:19:43 2022
    On Wednesday, August 10, 2022 at 9:03:42 PM UTC+2, pd wrote:
    I was reading about the event loop to understand how it's implemented in tcl, in short I've learnt the event loop relies basically in three elements: the event generator called the notifier, the event loop itself called tcl_DoOneEvent and event
    consumers which are essentially callback procs.

    As far as I understand the notifier is a kind of wrapper over system events translating them to tcl events stored in a tcl event queue. The event loop Tcl_DoOneEvent consume events from that queue calling the "subscribed" procs, you init the even loop
    by calling a special tcl command (vwait, fileevent...) indicating what proc is to be called when the right kind of event is processed in the event queue.

    I understand that you are asking quite a specific question, but your interest might come from an actual issue that you encountered. That's why I repeat my aha moment under this thread name; sorry if it seems unrelated or obvious ...

    On Tuesday, February 17, 2015 at 5:11:14 PM UTC+1, Rich wrote:
    heinrichmartin wrote:

    So Tcl does not have "the event loop", but stacked event loops, and
    update does not enter "the event loop", but "the current event loop", which was new to me ...

    I can see two improvements to vwait's doc now:

    - This command enters the Tcl event loop to process events, ...
    + This command enters a newly created Tcl event loop to process events, ...

    - In some cases the vwait command may not return immediately after
    - varName is set. This happens if the event handler that sets varName
    - does not complete immediately.
    + vwait does not return immediately after varName is set, but only
    + after all active event handlers have completed.

    Both are already documented, just not adjacent to those two sections,
    but a bit further within the man page:

    man vwait:

    ...
    To be clear, multiple vwait calls will nest and will not happen in
    parallel. The outermost call to vwait will not return until all
    the inner ones do.
    ...

    I.e. tcl_DoOneEvent might not trigger the event that you would have expected (when nested invocations are involved).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)