Merge from emacs-24; up to 2012-04-21T14:12:27Z!sdl.web@gmail.com

2 files changed, 27 insertions, 1 deletions

diff --git a/src/ChangeLog b/src/ChangeLog
index 4bf848d953a..596133002ea 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,11 @@
+2012-05-09  Eli Zaretskii  <eliz@gnu.org>
+
+        * w32proc.c (new_child): Force Windows to reserve only 64KB of
+        stack for each reader_thread, instead of defaulting to 8MB
+        determined by the linker.  This avoids failures in creating
+        subprocesses on Windows 7, see the discussion in this thread:
+        http://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00119.html.
+
 2012-05-07  Jérémy Compostella  <jeremy.compostella@gmail.com>
 
         Fix up display of the *Minibuf-0* buffer in the mini window.
diff --git a/src/w32proc.c b/src/w32proc.c
index 28591f90128..5bdeba25958 100644
--- a/src/w32proc.c
+++ b/src/w32proc.c
@@ -141,7 +141,25 @@ new_child (void)
       cp->char_consumed = CreateEvent (NULL, FALSE, FALSE, NULL);
       if (cp->char_consumed)
         {
-          cp->thrd = CreateThread (NULL, 1024, reader_thread, cp, 0, &id);
+          /* 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);
           if (cp->thrd)
             return cp;
         }