From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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> From: Eli Zaretskii To: Tom Tromey Cc: gdb-patches@sourceware.org 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-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * 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: Wed, 03 Aug 2022 13:34:00 -0000 > 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.