Re: [TCLCORE] External event loops & notifiers

[Alexandre F. <ale...@gm...>]

On Sun, Nov 10, 2013 at 2:40 PM, Michiel de Hoon <mjl...@ya...> wrote:
> Hello,
>
> Suppose I have an application that runs its own event loop.
> This application may or may not use Tcl; if it does, the event loop should handle events generated by Tcl appropriately.
> Can this be done? From reading the Tcl documentation on notifiers & external event loops, it seems that all the required functionality is available in Tcl to use such external event loops. However, when I try to implement this, I get stumped.
>
> In particular, how does the external event loop find out about the Tcl event sources it should pay attention to?
> I guess that I need to call Tcl_DoOneEvent to traverse the Tcl event sources and call setupProc, checkProc on them.
> However, if I call Tcl_DoOneEvent with the TCL_DONT_WAIT flag, I won't find out about Tcl timers.
> But if I call Tcl_DoOneEvent without the TCL_DONT_WAIT flag, then I will stay in Tcl_DoOneEvent and ignore all non-Tcl event sources.
> What is the right way to do this? Can somebody point me in the right direction?

There are two different approaches:

 (a) "Tcl-evloop-centric":  you extend Tcl's event loop with
Tcl_CreateEventSource; then use the event loop as usual from
scriptland (vwait,update).

 (b) "External-evloop-centric": you handle your own (blocking or not)
event stream, and periodically poll Tcl's
(Tcl_DoOneEvent+TCL_DONT_WAIT).

Clearly, (a) is more ambitious as it aims at a seamless integration;
but it is not directly doable for "alien" event sources involving
nonstandard system primitives (Tcl knows only about timers and select
masks); for them you'll likely need extra machinery like pipes and
threads. Conversely, (b) is a quick, dirty, and less that optimal
method in that it imposes a polling latency / CPU waste overhead.

Also note that a third "method" exists:

 (c) Two Separate Evloops: each one runs in its own process or thread;
sync occurs through usual IPC (sockets,pipes) or ITC (thread::send).

This one has my personal preference as it comes with a much improved
maintenability (easy unit testing). But that's just me.
Please clarify which way you want to dig ;)

-Alex