Re: Emacs-26 threads problem [win64]

[Eli Zaretskii <eliz@gnu.org>]

> From: Fabrice Popineau <fabrice.popineau@gmail.com>
> Date: Tue, 10 Oct 2017 22:14:58 +0200
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
>  > (while (> (length (all-threads)) 1)
>  > (sleep-for 0.1))
>  >
>  > This makes all the 28 tests pass.
> 
>  And the address of stack_pos doesn't grow anymore?
> 
> Yes, it still does. Apparently not out of bounds, because I have run the tests several times. 

Can you show the values?  What I see here is that it goes up one or 2
notches up to test #6, and then goes back and never grows in the rest
of the tests.

>  > A bit scary though.
> 
>  Why scary?
> 
> I don't like to be at the whim of such a waiting loop before being able to run another thread.

Since each thread uses up some stack space, why is it surprising that
given enough threads running, we get a C stack overflow?

Perhaps it's time to discuss whether we should place some restrictions
on the thread stack space.  Right now, we leave the stack size of the
thread to the system defaults, which in the Windows case means 8MB,
the size specified for the main program in the executable's header.
AFAIK, on Unix the default is 2MB, but can be changed via RLIMIT_STACK
setting.  Maybe these 2 values are too much, but OTOH these threads
need to be able to run the same Lisp programs as the main thread, so
it's unclear whether we can safely decrease the stack size.