From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id F00903858D20 for ; Thu, 2 May 2024 16:41:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F00903858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F00903858D20 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=96.47.72.81 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1714668087; cv=pass; b=tskQwMJdm5Z1u/6CCQSlFHixyvKDEXNrPOwvUTU7pQa8KMy7HUQtq2ZIWTuSB90r3oZjOmgHv5PpYF4o03gv/93lDI6DuhiW1WJR+Bjphh147kztWgLU4XMC258IeShrq8HBa2CYwiyenakHozDIqyTEkN7htKO+OeRbRiOmhWk= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1714668087; c=relaxed/simple; bh=/cbI3LdQw1x1RX2rH+d4eNbQ/SDl6DQP2IQdp/m+8E0=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=SB0+9gvZR5zVeQrbrTVQmAI0FGTpd0U6iHNZRgDUpszoyhHHWMcjYoJCJSVhXQhPVj0XJj62wuMMDJX9nXMo9KBlC8eGybXxnzgXUJaIRC3H83Of7zp9uCSlslRmSs+bRJntpDbL+qBeVF6OIsY0qooSuD0g416S27r3dHTntJA= ARC-Authentication-Results: i=2; server2.sourceware.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4VVfpF4jTJz4dBx; Thu, 2 May 2024 16:41:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VVfpF3NlTz4XxQ; Thu, 2 May 2024 16:41:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714668085; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bIV8vJnNkmfPJKelqzhiP8wHO90hLODbTLJVWpgMt/Q=; b=yP6Kq5zQmxxoUu/OhJyZkp9G7rBoM52f5vNnfEy2BRtqrw8/qwdzAYjCl36pJQPAJuHxM2 GQiAkKZLsj3m7Ne8A/Z+Zbh05gDG7KnDEzIZ/0v4tjOo/DU/wE7O//EztYBR1m4QJB/NLQ tH1IfLaHkmzSp0SpdnQSFGpfQ2rbfsdYkHq7ccKWbnvqOcvwxebv0XgHbZQacWhRbntlXH SnzAm7d8WoMvwxoMPzl9//cxOjD7GBtTRGs5WAceDl9y9KHHbSAxjsDGimfBDdHWhNMe+t uDRMGcFD7GjJT4Cmx4te+n22s04H5ZMHuPWZh4xHwSpkZ81TR0YU3+JYCSeCMQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1714668085; a=rsa-sha256; cv=none; b=PtGA6NvFSWGgcE/71SEjj10OPstQVcei9mjMUoKQ578NtcDstu4DGiczXsiydsTBHLmTSU bagEtxLol4MqhdtkCRFLbc7P2lOQj/ytzV5wTH/p8/NM4I3RnJ6g9WfBWR6qFMSm2MOnPq h6o4RUAKYwhOyxm9e/kl6i+8WYPDWWjJWD0uX4lREQ8wu2yOE1rmChc9Zk2+DxuPUIq43y zgJ+CWTwty45fqgIiAUQSKu6h+2LZOL5+0nIrHoI1ysioOaKB81C1TdabHhgcnJ80hra0U TVLKP7DNaruneTDh/JmrPfFDv7uE2yRF4bDdQaOupJuhVFaBGW9weUxKjneppQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1714668085; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bIV8vJnNkmfPJKelqzhiP8wHO90hLODbTLJVWpgMt/Q=; b=OyAzWr2p70gu3w2lgoMCGV9ShB52vbArNgTWv6xvuLR47+wRjz9Ogu6FMVZZ63DMa7DHGJ 6DVtGhrqsT0O5CdON6bJXvFRu3iai2S2JczySPblqRPfT2frjOsygC/xF3LxvJ3q8hGE8M P7V4RVAUocwxswQ8QKL2mg+KkfFNNgrR/PifRR1S0gw2cDbKmskpZjzO99t/UuTi84gbFL TtaMAvnKIcTa/u1PG386wP+MLH7APEW7xezR9AtdggGNpcqvB2fgrs2m36NDPD7XIyOOco 7PEVZqoKGg/Mnb5Mc03esx7SvtnkXTu9yeKSUIgjWhH2ufvXjPv9c5AMX8pjKQ== Received: from [IPV6:2601:644:937f:4c50:58ce:9dde:82e6:3594] (unknown [IPv6:2601:644:937f:4c50:58ce:9dde:82e6:3594]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4VVfpD5hKqz1KX9; Thu, 2 May 2024 16:41:24 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <6c90f4ec-782c-4a67-975c-95c173800fac@FreeBSD.org> Date: Thu, 2 May 2024 09:41:23 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3] [RFC] Fix AIX thread exit events not being reported and UI to show kernel thread ID. Content-Language: en-US To: Ulrich Weigand , "akamath996@gmail.com" , "tom@tromey.com" Cc: "gdb-patches@sourceware.org" , Aditya Kamath1 , Sangamesh Mallayya References: <20240502142944.14445-1-akamath996@gmail.com> <1e5a9e180681b4412e37f62257ba4e9ae70dcd55.camel@de.ibm.com> From: John Baldwin In-Reply-To: <1e5a9e180681b4412e37f62257ba4e9ae70dcd55.camel@de.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/2/24 9:30 AM, Ulrich Weigand wrote: > Aditya Vidyadhar Kamath wrote: > >> + /* Describes the number of thread exit events reported. */ >> + std::unordered_set exited_threads; >> + >> + /* Describes if thread is still in queue and not in unknown state. */ >> + std::vector in_queue_threads; > > I don't really like these new global variables. exited_threads > seems to be only ever added to, so it will just keep growing > forever? in_queue_threads seems to be fully local to the > sync_threadlists routine, so why is it not just a local > variable there? I think exited_threads is not global but per-inferior? in_queue_threads does indeed seem to be something that could be local to the function. > As a more general question, I'm wondering why you're completely > changing the way sync_threadlists works. I think the overall > idea of sync_threadslists, i.e. to compare the thread list of > the OS with GDB's thread list and then update the latter to > match the former, is still valid. I thought you'd simply change > the way the "pbuf" list is generated to filter out those threads > that the OS considers in terminated state. I think in this case it's a bit different as the internal list from pbuf "grows forever" (specifically, exited threads do not get removed from the thread library's internal list it seems, just remain forever as an exited thread). In that case, you don't have to extract two thread lists so that you can walk the union of the two lists looking for mismatches. Instead, the pbuf list will always be a superset of GDB's list, so it is sufficient to walk the pbuf list and decide how to handle each thread. (I must say that I'm surprised by the behavior of exited threads staying in AIX's thread library list forever, but it does seem to be the case.) -- John Baldwin