From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lndn.lancelotsix.com (lndn.lancelotsix.com [51.195.220.111]) by sourceware.org (Postfix) with ESMTPS id 7DFCC3858D35 for ; Fri, 4 Nov 2022 23:17:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7DFCC3858D35 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=lancelotsix.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lancelotsix.com Received: from ubuntu.lan (unknown [IPv6:2a02:390:9086::635]) by lndn.lancelotsix.com (Postfix) with ESMTPSA id 8CEB280017; Fri, 4 Nov 2022 23:17:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lancelotsix.com; s=2021; t=1667603867; bh=BydVa2YhSt08qH3P7cY32m2g9YV5QgN1axToPh9FpZg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=motXk3hK+6N2uO8f04bpeC7u4c+lWagfUqmGTrgv667GoPAkSnFlCXtqoQdjw0iVw ANr4xUo9Zm87nSoZI0mpRJ3ZHyD1zcNpX0wXz2JuwF+1aUk/7PdZowfB1hG2vaB93+ AwWH9l6GMODGYqcrGx2Rivgy5fGpzkhNuFeKHYtGFae1zDpd9SvZh/RIkwYxPVkDnl 16NUNY38LwOKlhi0VioX89bfjg7p5dxA8FzQMWQTIQggwDS5v51GSQ31e6GFbZ+Hjr GB9LdZAx95ZkjmKEuR4InzKGJsJAenm7X/p8DEIDRNBvdcJZ+yubmx3/ZtvEJj5GnS qoS8gMJGXDn4g== Date: Fri, 4 Nov 2022 23:17:34 +0000 From: Lancelot SIX To: Andrew Burgess Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 11/12] gdb: add timeouts for inferior function calls Message-ID: <20221104231700.evhnzbuwexevh2hd@ubuntu.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (lndn.lancelotsix.com [0.0.0.0]); Fri, 04 Nov 2022 23:17:47 +0000 (UTC) X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, > In this commit I propose a solution to this problem. A timeout. For > targets that support async-mode we can install an event-loop timer > before starting the inferior function call. When the timer expires we > will stop the thread performing the inferior function call. With this > mechanism in place a user can be sure that any inferior call they make > will either complete, or timeout eventually. > > Adding a timer like this is obviously a change in behaviour for the > more common 'call' and 'print' uses of inferior function calls, so, in > this patch, I propose having two different timers. One I call the > 'direct-call-timeout', which is used for 'call' and 'print' commands. > This timeout is by default set to unlimited, which, not surprisingly, > means there is no timeout in place. > > A second timer, which I've called 'indirect-call-timeout', is used for > inferior function calls from breakpoint conditions. This timeout has > a default value of 300 seconds. This is still a pretty substantial > time to be waiting for a single inferior call to complete, but I > didn't want to be too aggressive with the value I selected. A user > can, of course, still use Ctrl-c to interrupt an inferior function > call, but this limit will ensure that GDB will stop at some point. > I do see the use of the indirect call timeouts, and I find it a good solution for the problem you are trying to solve. I am however not sure I see much usecase for the direct one. It looks to me that using Ctrl-C serves this purpose well already. Do you have a use case in mind where this can come in handy? Scripting and automation maybe? It seems to me that only having the setting for the indirect call timeout would make the interface simpler. That being said, once you have implemented the mechanism for the "indirect" calls, "direct" call timeout implementation comes for free. I guess this was your reasoning. Lancelot.