From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8X5XC0F0/2KXsikAWB0awg (envelope-from ) for ; Fri, 19 Aug 2022 07:30:09 -0400 Received: by simark.ca (Postfix, from userid 112) id 210241E4A7; Fri, 19 Aug 2022 07:30:09 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=a1A93h0P; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 3FB3F1E222 for ; Fri, 19 Aug 2022 07:30:02 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 588863858288 for ; Fri, 19 Aug 2022 11:30:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 588863858288 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1660908601; bh=Yt7Hmx+VDhihgXTGmblbRvH4VrnSwrmyyhpTOV8YzzE=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=a1A93h0PbCFd2r3eoBNR+I8WoGdnhTI08hQ18v8/oU9n3o1HrRB+okgGOhTMwmmws ZN3nuRTjLpGyVEMERyPc2rX+FYxyT1VJrV6qXJGXYPDmV6/FviDWj5/okjtPCJTQcS 8Rpn3gQ326CbvibNYs8fbNCiorHj12fg/wnyM2S4= 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> In-Reply-To: <87tu69ajj0.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: , From: Patrick Monnerat via Gdb-patches Reply-To: Patrick Monnerat Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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