GNU bug report logs - #76041
31.0.50; comments above creating reader_thread in w32proc.c can be improved

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Yue Yi" <include_yy <at> qq.com>
To: "bug-gnu-emacs" <bug-gnu-emacs <at> gnu.org>
Subject: 31.0.50;
 comments above creating reader_thread in w32proc.c can be improved
Date: Tue, 4 Feb 2025 12:54:51 +0800

[Message part 1 (text/plain, inline)]

Hello Emacs, In w32proc.c, Child Process's reader_thread is created as follow: /* The 0x00010000 flag is STACK_SIZE_PARAM_IS_A_RESERVATION.    It means that the 64K stack we are requesting in the 2nd    argument is how much memory should be reserved for the    stack.  If we don't use this flag, the memory requested    by the 2nd argument is the amount actually _committed_,    but Windows reserves 8MB of memory for each thread's    stack.  (The 8MB figure comes from the -stack    command-line argument we pass to the linker when building    Emacs, but that's because we need a large stack for    Emacs's main thread.)  Since we request 2GB of reserved    memory at startup (see w32heap.c), which is close to the    maximum memory available for a 32-bit process on Windows,    the 8MB reservation for each thread causes failures in    starting subprocesses, because we create a thread running    reader_thread for each subprocess.  As 8MB of stack is    way too much for reader_thread, forcing Windows to    reserve less wins the day.  */ cp->thrd = CreateThread (NULL, 64 * 1024, reader_thread, cp, 			   0x00010000, &id); I could not find any references to the 2GB limit in the current Emacs (c4a67a4) source code in src/w32heap.c. After some investigation, I found that the earliest commit related to this was fab624a: Allow the Windows build to use up to 2GB of heap, along with the related discussion: https://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00119.html 81abbb9 * Fix bug #13065 with file selector dialog on Windows 7. On May 28, 2014, Fabrice Popineau replaced GNU's malloc with the system¡¯s allocation functions in commit 587fd08, and allocate_heap was removed. Therefore, I believe the above comment is somewhat outdated. My suggestion is to remove the 2GB-related part in the comment. Allocating a small amount of stack space for each reader_thread still makes sense, because excessive threads would consume too much address space on a 32-bit system. Additionally, I noticed the recent merge of no-purespace, which removed support for unexec. The alias for RtlCreateHeap_Proc in win32heap.c and the related comment seem to be redundant now. Best regards, Yue Yi

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.