From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id enojCUVuXWLPfQAAWB0awg (envelope-from ) for ; Mon, 18 Apr 2022 09:57:25 -0400 Received: by simark.ca (Postfix, from userid 112) id 156771F327; Mon, 18 Apr 2022 09:57:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham 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 0B1211E150 for ; Mon, 18 Apr 2022 09:57:24 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5A7813857419 for ; Mon, 18 Apr 2022 13:57:23 +0000 (GMT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by sourceware.org (Postfix) with ESMTPS id 296AB3858D28 for ; Mon, 18 Apr 2022 13:57:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 296AB3858D28 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 cmgw14.mail.unifiedlayer.com (unknown [10.0.90.129]) by progateway6.mail.pro1.eigbox.com (Postfix) with ESMTP id 61AD410048801 for ; Mon, 18 Apr 2022 13:57:11 +0000 (UTC) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTP id gRsMnJUdc53CXgRsNn1GcB; Mon, 18 Apr 2022 13:57:11 +0000 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.4 cv=OPfiYQWB c=1 sm=1 tr=0 ts=625d6e37 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=z0gMJWrwH1QA:10:nop_rcvd_month_year a=Qbun_eYptAEA:10:endurance_base64_authed_username_1 a=CCpqsmhAAAAA:8 a=DrBAFTcON8crFMQ8zHQA: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=OZtESeOKSr/p1Kd4WyBzcmO7Nm+D+3xfLN81Sk+JJOw=; b=Wbos45wh5h01Nc2awvfOFffYqk LUTi9wPMLPRr/Dh7v3Sd5mi0tzUKD0l1Vos4OypGWCkSByjTphUH6r60ZOtlLoe2vv7uopauCaD1x 03n3zWccvcxfB7nYctgeD5T1/; Received: from 71-211-154-204.hlrn.qwest.net ([71.211.154.204]:55592 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ngRsM-003w79-Mb; Mon, 18 Apr 2022 07:57:10 -0600 From: Tom Tromey To: Simon Farre via Gdb-patches Subject: Re: [PATCH v2] gdb/Python: Added ThreadExitedEvent References: <20220412090315.1142824-1-simon.farre.cx@gmail.com> <87bkx2z0e6.fsf@tromey.com> X-Attribution: Tom Date: Mon, 18 Apr 2022 07:57:09 -0600 In-Reply-To: (Simon Farre via Gdb-patches's message of "Mon, 18 Apr 2022 12:30:22 +0200") Message-ID: <87lew2xznu.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.154.204 X-Source-L: No X-Exim-ID: 1ngRsM-003w79-Mb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-211-154-204.hlrn.qwest.net (murgatroyd) [71.211.154.204]:55592 X-Source-Auth: tom+tromey.com X-Email-Count: 12 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes 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: , Cc: Tom Tromey Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" >>>>> Simon Farre via Gdb-patches writes: > So my reasoning for this was; since the thread is exiting it is dying, > and from a Python perspective I thought it proper not to hold on to > any resources that GDB otherwise would dispose of. I'm open to > suggestions for whether or not this logic is sound. gdb uses a maybe-weird approach to lifetime management. Normally, a Python object isn't allowed to keep some underlying gdb object alive. So, if an inferior thread exits, the gdb data structures will be cleaned up. However, the InferiorThread wrapper object may live on -- but now it is in a special invalid date. This approach is why a bunch of types, like InferiorThread, have an 'is_valid' method. So, it's fine to emit this event with the InferiorThread object. If the Python code capture it, that will be fine. (Though of course this probably won't normally happen anyway.) gdb could probably be better about notifying Python about these transitions to the invalid state. I feel like there's some Python protocol in this area that gdb should participate in but does not. Like, it may be useful for using these objects as keys in a weak map. > It's currently emitted inside `delete_thread_object` which is a > function that is attached to the observer > `gdb::observers::thread_exit` in py-inferior.c. So if we are to return > a reference to the thread object, the function attached here should > probably be removed entirely and replaced with just emitting the newly > introduced "thread exit event" (and handle the de-allocation of the > thread object inside the thread exit event type tp_dealloc function). I think the current placement of the code is correct. I'm not sure I understand the tp_dealloc comment, but I don't think a change there is needed. Tom