#5123 cannot set thread stack size on linux

[Jeff Rogers]

recent versions of Linux support pthread_attr_setstacksize, but HAVE_PTHREAD_ATTR_SETSTACKSIZE is not defined for linux. As a result, no stack size requests are handed in Tcl_CreateThread, meaning the default is always used. On linux the default stack size is the maximum possible stack size (i.e., the RLIMIT_STACK soft limit at program start time), which is typically 8Mb.

Even if stack size setting was enabled for linux, the notifier thread is created with the default size, and this is not changeable, meaning every threaded tclsh has minimum 8Mb overhead, even if no application threads are used.

[Alexandre Ferrieux]

While the suggestion to allow this setting is obviously valid, please notice that on Linux systems this "8Mb overhead" only costs in virtual address space, not real RAM, thanks to overcommit. To verify this, let's look at a 8.6HEAD threaded build on Linux 32b:

Notifier thread stack segment as seen in pmap: 10MB

b6e93000 10248K rw--- [ anon ]

Real usage as seen in /proc/PID/smaps: only 16kB

b6e93000-b7895000 rw-p 00000000 00:00 0
Size: 10248 kB
Rss: 16 kB
Pss: 16 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 16 kB
Referenced: 16 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB

[Jeff Rogers]

This does limit the number of threads that can be created on a 32-bit system to a much smaller number (around 365 on my machine) than would otherwise be the case.

It's possible to adjust the overcommit behavior, although I doubt doing so is very common.

It also may be the case (I wasn't able to find a definitive answer one way or the other) that in some virtualized environments (e.g., OpenVZ) the OOM killer looks at allocated rather than used pages. This could lead to threaded apps being unfairly targeted.