Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Trying to fully understand the event loop
111 views
Skip to first unread message
pd
Aug 10, 2022, 3:03:42 PM8/10/22
to
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
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
apn
Aug 10, 2022, 11:02:04 PM8/10/22
to
On 8/11/2022 12:33 AM, pd wrote:> I mean, It's said the tcl 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
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.
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)
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
Harald Oehlmann
Aug 11, 2022, 2:59:40 AM8/11/22
to
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
heinrichmartin
Aug 11, 2022, 3:19:45 AM8/11/22
to
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 ...
> 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.
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).
0 new messages