Re: [PATCH] Add a timeout parameter to gdb_do_one_event

[Patrick Monnerat via Gdb-patches <gdb-patches@sourceware.org>]

On 4/15/22 18:21, Tom Tromey wrote:
>>>>>> "Patrick" == Patrick Monnerat via Gdb-patches <gdb-patches@sourceware.org> writes:
> Patrick> As Insight uses a GUI that has its own event loop, gdb and GUI event
> Patrick> loops have then to be "merged" (i.e.: work together). But this is
> Patrick> problematic as gdb_do_one_event is not aware of this alternate event
> Patrick> loop and thus may wait forever.
>
> Can Insight fds just be added to the GDB event loop?
In fact, the alternate event loop is the one of Tcl. Fortunately, Tcl 
features a "notifier" (at the C API level) that allows it to connect 
with an external event handler (in our case, gdb_do_one_event()). 
Insight already uses a notifier to handle Tcl own fds via the GDB event 
loop.
> Patrick> The solution is to implement a wait timeout to gdb_do_one_event. This
> Patrick> cannot be done externally as gdb timers are event sources themselves.
>
> I guess what you're doing is Insight is calling gdb_do_one_event
> repeatedly?  And you want it to exit with a timeout so you can then run
> the Insight event loop?
Not at all ! This is not a "parallel" monitoring, but a "nested" one.
> I don't really know the scenario here  so I am just guessing.
The real thing is: Tcl event dispatcher calls gdb_do_one_event() via the 
notifier. There's no real event loop in Insight itself (this is not 
possible anymore after commit b2d8657). We fully rely on the GDB event 
loop to dispatch events either to GDB or to Tcl The latter can then 
dispatch/schedule/monitor/wait events itself (infinite recursion was 
hard to avoid there !). The timeout is a Tcl requirement.
>
> Anyway I don't understand why installing your own timer wouldn't work.
> It seems to me that if a timer is handled, gdb_do_one_event will return.

The problem is: the timeout can be 0ms. Calls with such a timeout are 
supposed to serve pending events, if some.

If an "own" timer were used, it would be an event source by itself. A 
0ms "own" timer prevents other pending events to be handled in 1 out of 
3 gdb_do_one_event() calls, which is not what we want. The effective 
timeout value (if some) is under control of Tcl.

Note that Tcl has an internal "idle" event type. Callbacks in the idle 
queue are not supposed to be called if another event is pending. An 
"own" timer will make it fail 1/3 times.

The solution implemented in the patch creates a timer only to limit the 
wait time by reusing the limiting code that is already in place in GDB. 
This is done AFTER having monitored pending events. It should normally 
never be seen as an event source (the lambda callback should never be 
called).


As you can see, the real work is to interconnect GDB and Tcl event 
handlers. Except in the notifier that does this job, Insight C code does 
not much use the event handler(s).

I hope these explanations are clear enough: the context is not very easy 
to explain !

Thanks for your interest.

Patrick