From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from jupiter.monnerat.net (jupiter.monnerat.net [46.226.111.226]) by sourceware.org (Postfix) with ESMTPS id 26D133858D28 for ; Fri, 19 Aug 2022 11:29:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 26D133858D28 Received: from [192.168.0.128] ([192.168.0.128]) by jupiter.monnerat.net (8.14.8/8.14.8) with ESMTP id 27JBTVU2010404 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=OK); Fri, 19 Aug 2022 13:29:36 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 jupiter.monnerat.net 27JBTVU2010404 Message-ID: Date: Fri, 19 Aug 2022 13:29:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: [PATCH] Add a timeout parameter to gdb_do_one_event Content-Language: en-US To: Andrew Burgess , gdb-patches@sourceware.org References: <20220317130846.162955-1-patrick@monnerat.net> <87tu69ajj0.fsf@redhat.com> From: Patrick Monnerat In-Reply-To: <87tu69ajj0.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2022 11:29:43 -0000 On 8/18/22 13:16, Andrew Burgess wrote: > Patrick Monnerat via Gdb-patches 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