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

Previous Next

To reply to this bug, email your comments to 76041 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Yue Yi" <include_yy <at> qq.com>
Cc: 76041 <at> debbugs.gnu.org
Subject: Re: bug#76041: 31.0.50;
 comments above creating reader_thread in w32proc.c can be improved
Date: Tue, 04 Feb 2025 15:45:59 +0200

> Date: Tue, 4 Feb 2025 12:54:51 +0800
> From:  "Yue Yi" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 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.

Yes, okay.

> 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.

Right.  In particular, if we want to support 1024 subprocesses, which
means more than 1000 threads, giving 8MB of stack to each of those
threads is impossible for 32-bit Emacs.

> 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.

That's true, but let's wait with removing these until Po Lu says he's
done with handling the fallout of unexec removal.

Previous Next

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