From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RIk9EImCTGjS6gwAWB0awg (envelope-from ) for ; Fri, 13 Jun 2025 15:56:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749844617; bh=c/XCw74U9tcmdJ8sx2enWrexlSU5d6aUJAVgBXJeXLc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=R1mgROF25iUqMjxIk7/oPvPlMmV3KMORxY/rnc4DAUeXUBVTIR+vol1wVn2KKLmhR WFn/5KjrF8D4FL1qkri0F7CoorVR2oV+aNr587Z3xaNRHVqe0+RX1QMukNzsy16EM6 D8yIuCqjqpJ5G8bPvXcF1JQqMBp4rXyMOfZ/S+n8= Received: by simark.ca (Postfix, from userid 112) id 31FD21E102; Fri, 13 Jun 2025 15:56:57 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-9.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE autolearn=unavailable autolearn_force=no version=4.0.1 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vVFaxd0e; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=SU8Jes/q; dkim-atps=neutral Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id D31A21E0C2 for ; Fri, 13 Jun 2025 15:56:56 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6DBEA388FF44 for ; Fri, 13 Jun 2025 19:56:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6DBEA388FF44 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=vVFaxd0e; dkim=pass (1024-bit key) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=SU8Jes/q Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 5D52F3970738 for ; Fri, 13 Jun 2025 19:56:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5D52F3970738 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5D52F3970738 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749844581; cv=none; b=IZ4xtlyC4w59+1lkI8wWDPVOZEm2WZAm1ApcVmRgswvdPUZb7nprKW31nJX+2osBUr0bwaFepj6c+bLZ6yWjDxF06bvNJ80/tUuPx6ND2yh+WsQfovRzHfeq3+vQr1zDIfIDY4qfljUMj26ENNw+Bj71DQsXcFT8+eKbPTXuyMo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1749844581; c=relaxed/simple; bh=c/XCw74U9tcmdJ8sx2enWrexlSU5d6aUJAVgBXJeXLc=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:MIME-Version: Subject:To:From; b=GVhEQmt36P3ZSowqwboAuFLAcvioM0KUwbj+7PbFXVHQp1FsGra6dn/POZFbuGwycvCk3fj03HWadqjwgk88gSsRhZJSBjQY2ycUg/EIq6qkci6OVUdnBkRQXbjfekrXB8lD3w4aZQY/eU3KiEHM6I4t2akADciWTO2YtWYR2SI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5D52F3970738 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749844581; bh=c/XCw74U9tcmdJ8sx2enWrexlSU5d6aUJAVgBXJeXLc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vVFaxd0esivfdt7UgPLJf/km6pEqJP2nf0gio6d82v7m0bgeFc9aIOwrKmSXMiU+Z PI8AbwjVwOTbNaDJlintH9kOIOKVInOuyXApEyJVBsNBuYUuk5NEUPTlnGOO9xiPZT 02YGkc0jrFz8WvvnmeoKuetQyq9P2GT632L/1cpc= Received: by simark.ca (Postfix, from userid 112) id 1A1981E102; Fri, 13 Jun 2025 15:56:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1749844579; bh=c/XCw74U9tcmdJ8sx2enWrexlSU5d6aUJAVgBXJeXLc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=SU8Jes/qd3o9H7RW51YeQePzcoLDjuvgZ3hKPA+fCGXEhQe1jwg5zRxkwaEyR1jPd 0JFVi5+OwKWp+wBqgKGPI6bH1i+2bunnYGxN78UJJFSBuQL7PuVIF4ce72wX+zlZKe ucFsaeQSu8qckSlRWyBtyTqlaxsfXXILozamqcGM= Received: from [172.16.0.192] (192-222-132-26.qc.cable.ebox.net [192.222.132.26]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id AB5101E0C2; Fri, 13 Jun 2025 15:56:18 -0400 (EDT) Message-ID: Date: Fri, 13 Jun 2025 15:56:18 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 3/6] gdbsupport: use dynamic partitioning in gdb::parallel_for_each To: Simon Marchi , Tom Tromey , Simon Marchi Cc: gdb-patches@sourceware.org References: <20250505201548.184917-1-simon.marchi@efficios.com> <20250505201548.184917-3-simon.marchi@efficios.com> <87tt4jjy13.fsf@tromey.com> <46f028fd-14f8-49a5-afc1-d6661d6f84ac@polymtl.ca> Content-Language: fr From: Simon Marchi In-Reply-To: <46f028fd-14f8-49a5-afc1-d6661d6f84ac@polymtl.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 6/13/25 3:22 PM, Simon Marchi wrote: > Another idea I had (but didn't try) was to make lambdas receive a > "magic" range object, like athis: > > [&] (gdb::dynamic_range range) > { > for (dwarf2_per_cu *cu : range) > process_unit (cu); > } > > "range" would get work items from the work queue in batches, but yield > one at a time. It would reach its end when the work queue is empty. > It will be a bit of work to implement, but it would have the advantage > that any per-worker state could be right there in the lambda, like we > have today. Ah, I remembered why I didn't do this. It wouldn't play well with how minimal_symbol_reader::install() currently uses gdb::parallel_for_each. Currently, it receives one contiguous range [start,end). After having computed the demangled names and hashes for the whole range, each worker locks a mutex and installs the names in a shared hash table. In my patch, it's similar, but each worker installs the names in the share hash table at the end of each small range it receives. With my "magic" iterator idea, it wouldn't be clear when and how to install the names in the shared hash table. Simon