From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GfIYLxgQWmKiewAAWB0awg (envelope-from ) for ; Fri, 15 Apr 2022 20:38:48 -0400 Received: by simark.ca (Postfix, from userid 112) id AC5751F327; Fri, 15 Apr 2022 20:38:48 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.9 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.2 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 224B01E787 for ; Fri, 15 Apr 2022 20:38:48 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6A25F3857C4A for ; Sat, 16 Apr 2022 00:38:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6A25F3857C4A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1650069527; bh=m+2ayTphzh8WdWYnGv91M5ag5Fgs+HZNj6SPSvRzBWw=; 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=WIlyqCBWMgRg8wK00+EdzJbmFGYQFkZmvitphDkCUkWk424Rx8AMU2slX6OBJqNeK h+wsZcadrIzqD7Y8PMp3X+C+Ar0gG6qyzS7+aip6MUbPprxoz6PMwmJybWk6xaYJFJ jhRG3nQupJwMdYkv3dg5I5fpuj9h71nDwpZEfEh0= Received: from jupiter.monnerat.net (jupiter.monnerat.net [46.226.111.226]) by sourceware.org (Postfix) with ESMTPS id 7D91C385803E for ; Sat, 16 Apr 2022 00:38:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D91C385803E Received: from [192.168.0.128] ([192.168.0.128]) by jupiter.monnerat.net (8.14.8/8.14.8) with ESMTP id 23G0cJRZ008881 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=OK); Sat, 16 Apr 2022 02:38:25 +0200 DKIM-Filter: OpenDKIM Filter v2.10.3 jupiter.monnerat.net 23G0cJRZ008881 Message-ID: <6e3beaf1-c0d6-3f34-811e-96296142d0f5@monnerat.net> Date: Sat, 16 Apr 2022 02:38:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH] Add a timeout parameter to gdb_do_one_event Content-Language: en-US To: Tom Tromey , Patrick Monnerat via Gdb-patches References: <20220317130846.162955-1-patrick@monnerat.net> <87a6cm1fn0.fsf@tromey.com> In-Reply-To: <87a6cm1fn0.fsf@tromey.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 4/15/22 18:21, Tom Tromey wrote: >>>>>> "Patrick" == Patrick Monnerat via Gdb-patches writes: > Patrick> As Insight uses a GUI that has its own event loop, gdb and GUI event > Patrick> loops have then to be "merged" (i.e.: work together). But this is > Patrick> problematic as gdb_do_one_event is not aware of this alternate event > Patrick> loop and thus may wait forever. > > Can Insight fds just be added to the GDB event loop? In fact, the alternate event loop is the one of Tcl. Fortunately, Tcl features a "notifier" (at the C API level) that allows it to connect with an external event handler (in our case, gdb_do_one_event()). Insight already uses a notifier to handle Tcl own fds via the GDB event loop. > Patrick> The solution is to implement a wait timeout to gdb_do_one_event. This > Patrick> cannot be done externally as gdb timers are event sources themselves. > > I guess what you're doing is Insight is calling gdb_do_one_event > repeatedly? And you want it to exit with a timeout so you can then run > the Insight event loop? Not at all ! This is not a "parallel" monitoring, but a "nested" one. > I don't really know the scenario here so I am just guessing. The real thing is: Tcl event dispatcher calls gdb_do_one_event() via the notifier. There's no real event loop in Insight itself (this is not possible anymore after commit b2d8657). We fully rely on the GDB event loop to dispatch events either to GDB or to Tcl The latter can then dispatch/schedule/monitor/wait events itself (infinite recursion was hard to avoid there !). The timeout is a Tcl requirement. > > Anyway I don't understand why installing your own timer wouldn't work. > It seems to me that if a timer is handled, gdb_do_one_event will return. The problem is: the timeout can be 0ms. Calls with such a timeout are supposed to serve pending events, if some. If an "own" timer were used, it would be an event source by itself. A 0ms "own" timer prevents other pending events to be handled in 1 out of 3 gdb_do_one_event() calls, which is not what we want. The effective timeout value (if some) is under control of Tcl. Note that Tcl has an internal "idle" event type. Callbacks in the idle queue are not supposed to be called if another event is pending. An "own" timer will make it fail 1/3 times. The solution implemented in the patch creates a timer only to limit the wait time by reusing the limiting code that is already in place in GDB. This is done AFTER having monitored pending events. It should normally never be seen as an event source (the lambda callback should never be called). As you can see, the real work is to interconnect GDB and Tcl event handlers. Except in the notifier that does this job, Insight C code does not much use the event handler(s). I hope these explanations are clear enough: the context is not very easy to explain ! Thanks for your interest. Patrick