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 19AC53858423 for ; Sat, 28 Aug 2021 00:07:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 19AC53858423 Received: from patrick.monnerat ([192.168.0.128]) by jupiter.monnerat.net (8.14.8/8.14.8) with ESMTP id 17S07XNd014127 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Aug 2021 02:07:38 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 jupiter.monnerat.net 17S07XNd014127 Subject: Re: [PATCH] Add a timeout parameter to gdb_do_one_event To: Tom Tromey , Patrick Monnerat via Gdb-patches References: <20210823182359.104456-1-patrick@monnerat.net> <4e3085bb-af40-e0dc-73aa-991f97243e06@polymtl.ca> <60a52fef-89f0-62f1-1a45-5e5a40f47df6@monnerat.net> <87wno6n4kw.fsf@tromey.com> From: Patrick Monnerat Message-ID: Date: Sat, 28 Aug 2021 02:07:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87wno6n4kw.fsf@tromey.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Status: No, score=-4.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 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Sat, 28 Aug 2021 00:08:04 -0000 On 8/27/21 8:08 PM, Tom Tromey wrote: >>>>>> "Patrick" == Patrick Monnerat via Gdb-patches writes: > Patrick> The real implementation makes the GUI event loop call gdb_do_one_event > Patrick> and recursively. The actual event waiting is performed by > Patrick> gdb_do_one_event, but the GUI may define a timeout for it. The hard > Patrick> task here is to avoid infinite recursion. > > I wonder sometimes how we'll handle integrating event loops when we want > to let users integrate Python await with GDB APIs. I don't know much about it. Would you monitor gdb events from Python or an asyncio event loop from gdb? In case you haven't seen it yet, I found that: https://docs.python.org/3/c-api/typeobj.html#async-object-structures. > > Patrick> The alternate solution would have been to run the GUI in a separate > Patrick> thread, but that's even a bigger work! > > This is what my Python GUI does, but indeed it's complicated. It needed > a hack (to block some signals in the GUI thread), and it has to send > Python code back and forth between the GUI thread and the main thread, > because GDB isn't thread-safe. Thanks for the comment Tom: it confirms what I "sniffed" ! I have to admit that, without the Tcl notifier feature, threads would have been the only solution. It was (almost) easy to use gdb event system from Tcl because the latter provides support for it. The opposite is not true: gdb events cannot be delegated to some external event monitoring handler. If Insight is not the only piece of software having to support alternate concurrent event loops, shouldn't we dream of such a gdb feature? Just my 2 cents! Patrick