[PATCH] Add a timeout parameter to gdb_do_one_event

[Patrick Monnerat]

On 8/18/22 13:16, Andrew Burgess wrote:
> Patrick Monnerat via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> @@ -229,17 +236,35 @@ gdb_do_one_event (void)
>>   	return 1;
>>       }
>>   
>> +  if (!mstimeout)
>> +    return 0;	/* Null timeout: do not wait for an event. */
>> +
> This should be:
>
>    if (mstimeout == 0)
>
> As mstimeout is an int, not a bool.

This patch has been pushed now (bac814a), but I will change that.

> More just a warning really, but this isn't going to work in all cases.
> If a target doesn't support async-mode then GDB will block waiting for
> events in the check_async_event_handlers call above, and never gets down
> this far.

Thanks for your remark.

 From what I can see in check_async_event_handlers, there is no direct 
waiting. The only delay/suspension can only come from an invoked handler 
while serving an event that is already active.

The timeout introduced here targets event waiting only and not things 
that may be consuming time in event handlers themselves.

Even with a timer controlled by the gdb_do_one_event caller, the current 
code can suspend a longer time.

But maybe I missed something?

>
> I'm interested in this because I also want to have the event loop run
> under a timeout for a patch I'm working on, and everything works fine
> except for the case when I run with async support disabled.
> I'm currently investigating having non-async targets ask the event loop
> for a maximum wait time before they block, then return to the event loop
> in order to check timers.
Obviously your needs are not exactly the same as mine: from what I can 
understand you want to "limit" the handler running time.
>
> If I can get this working, I'll want to move your create_timer call to
> the start of gdb_do_one_event, so that the timer is in place before the
> call to check_async_event_handlers - though I'm not quite sure how this
> would be expected to interact with the case where 'mstimeout == 0'.
Please don't! this proposal can be implemented with an "external" (i.e.: 
under caller's control) timer and I rejected this solution because using 
mstimeout=0 would cause legitimate pending event misses, the timer 
becoming an event source by itself! In other words, it should not exist 
when calling poll_timers.


Thanks for your comments,

Patrick