From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from progateway7-pub.mail.pro1.eigbox.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by sourceware.org (Postfix) with ESMTPS id DC08F385828B for ; Mon, 6 Jun 2022 12:51:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DC08F385828B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com Received: from cmgw12.mail.unifiedlayer.com (unknown [10.0.90.127]) by progateway7.mail.pro1.eigbox.com (Postfix) with ESMTP id F0DF01004810F for ; Mon, 6 Jun 2022 12:51:57 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id yCD7nAmL4wPf0yCD7njszd; Mon, 06 Jun 2022 12:51:57 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=F5ySyotN c=1 sm=1 tr=0 ts=629df86d a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=JPEYwPQDsx4A:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=0tdConKxYXmHQ_8lC4QA:9 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=epqeqGm/5k7T2WZhD/7a15qB3v2PpETnGmxFRqznwX0=; b=jUrBSfJZ9+EtgCCGsX37Q3i1s1 C8XVZOFb5N60XiuWd+r7RPOofpLt4Foszzeb5p35rAGAui64mjgenUOzUYNjPZ302JC2gZqLYlnp2 p1WB5ac/Mxi0mTLr8GxZJnhaw; Received: from 71-211-171-143.hlrn.qwest.net ([71.211.171.143]:55876 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1nyCD7-001j2w-8q; Mon, 06 Jun 2022 06:51:57 -0600 From: Tom Tromey To: Simon Farre via Gdb-patches Subject: Re: [PATCH v4] gdb/Python: Added ThreadExitedEvent References: <20220420082547.759990-1-simon.farre.cx@gmail.com> X-Attribution: Tom Date: Mon, 06 Jun 2022 06:51:56 -0600 In-Reply-To: <20220420082547.759990-1-simon.farre.cx@gmail.com> (Simon Farre via Gdb-patches's message of "Wed, 20 Apr 2022 10:25:47 +0200") Message-ID: <87pmjm0xar.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 71.211.171.143 X-Source-L: No X-Exim-ID: 1nyCD7-001j2w-8q X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-171-143.hlrn.qwest.net (murgatroyd) [71.211.171.143]:55876 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-Spam-Status: No, score=-3024.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Mon, 06 Jun 2022 12:52:01 -0000 >>>>> Simon Farre via Gdb-patches writes: > Tom requested that I should probably just emit the thread object; > I ran into two issues for this, which I could not resolve in this patch; > 1 - The Thread Object (the python type) checks it's own validity > by doing a comparison of it's `thread_info* thread` to nullptr. This > means that any access of it's attributes may (probably, since we are > in "async" land) throw Python exceptions because the thread has been > removed from the thread object. This seems fine to me, because the event emission comes before the clearing of the field: + if (!evregpy_no_listeners_p (gdb_py_events.thread_exited)) + { + if (emit_thread_exit_event (tmp->thread_obj->thread) < 0) + gdbpy_print_stack (); + } tmp->thread_obj->thread = NULL; The InferiorThread object is valid until that NULL assignment is done. > 2 - A python user can hold a global reference to an exiting thread. Thus > in order to have a ThreadExit event that can provide attribute access > reliably (both as a global reference, but also inside the thread exit > handler, as we can never guarantee that it's executed _before_ the > thread_info pointer is removed from the gdbpy thread object), > the `thread_info *` thread pointer must not be null. However, this > comes at the cost of gdb.InferiorThread believing it is "valid" - which means, > that if a user holds takes a global reference to that > exiting event thread object, they can some time later do `t.switch()` at which > point GDB will 'explode' so to speak. I think it will be fine because thread-switching checks validity using THPY_REQUIRE_VALID. So once the underlying (gdb) thread is gone, the InferiorThread will be in the "invalid" state, and all will be fine. Another way to look at it is that the user can already stash the InferiorThread somewhere and refer to it later. The reason I think it's better to pass the InferiorThread to the event is that (1) it means you can have a map where the key is a thread and then it is easy to update when a thread exits, and (2) this doesn't lose anything because the event can always refer to the members of the thread if that is what is useful. Tom