From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id fmL/MFp56mLt1R8AWB0awg (envelope-from ) for ; Wed, 03 Aug 2022 09:34:18 -0400 Received: by simark.ca (Postfix, from userid 112) id BBD0D1EA05; Wed, 3 Aug 2022 09:34:18 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=ZrbIwqSs; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 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 68A1A1E9EB for ; Wed, 3 Aug 2022 09:34:18 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CEAD23883030 for ; Wed, 3 Aug 2022 13:34:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CEAD23883030 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659533657; bh=Z1bBGUGtyRt5uMOPnFSjcnabZtnkX3LDqQN+HvuCNuI=; h=Date:To:In-Reply-To:Subject:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ZrbIwqSs3pFtEevJcSoug8Fblly1xVYxuxod35oZsddiHLDc/UY9jRFI8vb77fzcJ 7K8PIh3x/Pv1h2YhznVKo1SGRvL81nfzmF/ZPf5JihbDYXiYJYB4T11yzHv+2rHsfZ rls669E5WMnMbba3+dTjTBXHS5w9Dfb3UHgno9e0= Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 73DF5385117A for ; Wed, 3 Aug 2022 13:33:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73DF5385117A Received: from fencepost.gnu.org ([2001:470:142:3::e]:45190) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJEVZ-0002WW-SS; Wed, 03 Aug 2022 09:33:57 -0400 Received: from [87.69.77.57] (port=1784 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJEVZ-0005ux-50; Wed, 03 Aug 2022 09:33:57 -0400 Date: Wed, 03 Aug 2022 16:33:50 +0300 Message-Id: <83a68l5u4h.fsf@gnu.org> To: Tom Tromey In-Reply-To: <20220803130822.735057-2-tromey@adacore.com> (message from Tom Tromey via Gdb-patches on Wed, 3 Aug 2022 07:08:21 -0600) Subject: Re: [PATCH 1/2] Move some Windows operations to worker thread References: <20220803130822.735057-1-tromey@adacore.com> <20220803130822.735057-2-tromey@adacore.com> 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: Eli Zaretskii via Gdb-patches Reply-To: Eli Zaretskii Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Date: Wed, 3 Aug 2022 07:08:21 -0600 > From: Tom Tromey via Gdb-patches > Cc: Tom Tromey > > On Windows, certain debugging APIs can only be called from the thread > that started (or attached) to the inferior. Also, there is no way on > Windows to wait for a debug event in addition to other events. > Therefore, in order to implement target async for Windows, gdb will > have to call some functions in a worker thread. > > This patch implements the worker thread and moves the necessary > operations there. Target async isn't yet implemented, so this patch > does not cause any visible changes. Thanks! > + HANDLE bg_thread = CreateThread (nullptr, 0, fn, this, 0, nullptr); That zero in the 2nd argument of CreateThread means the worker thread will get the same stack size as the value recorded in the GDB executable file's header, which is 12MB according to my reading of gdb/Makefile, at least in my build? That's unlikely to be required for this thread, so I suggest to specify a non-zero value there instead. I guess 64KB should be enough? The downside of leaving it at zero is that the OS reserves the addresses of the entire stack space as for the GDB process, which could then prevent GDB from allocating enough memory for other purposes. And if we could start several such worker threads (is that possible in some usage scenario?), then we could simply run out of memory for no good reason, and the next thread will fail to start.