From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0AHjBHh+KWGYbAAAWB0awg (envelope-from ) for ; Fri, 27 Aug 2021 20:08:24 -0400 Received: by simark.ca (Postfix, from userid 112) id 10E851EE1B; Fri, 27 Aug 2021 20:08:24 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 91B511ECEB for ; Fri, 27 Aug 2021 20:08:23 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 03BB8385801A for ; Sat, 28 Aug 2021 00:08:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 03BB8385801A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1630109303; bh=aldQDpM9npkMBratt671hFHjUcWekcjmsmbMIRi/JMY=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=fH0M4Curoc0oSWmU4LQj55oEzHXDVvBuyMgY9ZLoS5I1KE7Kf+atZ1XSzEFpssCHo ZPejm4l58JSLqTHnfi91A2h4/FmKvKneRF4AHR1OwoAV6waSntRh/H9zao3H3Xl2Mv r0dn5N7g6MGJOSBzCusSq1haGGfNI4aUB8mvPruA= 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> 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-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/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