all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#76041: 31.0.50; comments above creating reader_thread in w32proc.c can be improved
@ 2025-02-04  4:54 Yue Yi via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2025-02-04 13:45 ` Eli Zaretskii
  0 siblings, 1 reply; 2+ messages in thread
From: Yue Yi via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2025-02-04  4:54 UTC (permalink / raw)
  To: 76041

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 2198 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2299 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

* bug#76041: 31.0.50; comments above creating reader_thread in w32proc.c can be improved
  2025-02-04  4:54 bug#76041: 31.0.50; comments above creating reader_thread in w32proc.c can be improved Yue Yi via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2025-02-04 13:45 ` Eli Zaretskii
  0 siblings, 0 replies; 2+ messages in thread
From: Eli Zaretskii @ 2025-02-04 13:45 UTC (permalink / raw)
  To: Yue Yi; +Cc: 76041

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1128 bytes --]

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





^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-02-04 13:45 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-02-04  4:54 bug#76041: 31.0.50; comments above creating reader_thread in w32proc.c can be improved Yue Yi via Bug reports for GNU Emacs, the Swiss army knife of text editors
2025-02-04 13:45 ` Eli Zaretskii

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.