Dynamically sizing the kernel stack

Posted May 30, 2024 8:06 UTC (Thu) by dongmk (subscriber, #131668)
Parent article: Dynamically sizing the kernel stack

> There are applications that create millions of threads

What kinds of applications need to create millions of threads, on a single machine? Can anyone share some more details about the specific scenario?

to post comments

Dynamically sizing the kernel stack

Posted May 30, 2024 8:29 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

> What kinds of applications need to create millions of threads, on a single machine?

Pretty much any application trying to solve a big problem with recursion? Okay, recursion is often used when it shouldn't be, but it's a quick-n-dirty fix that's very popular ...

Cheers,
Wol

Dynamically sizing the kernel stack

Posted May 30, 2024 18:30 UTC (Thu) by mrugiero (guest, #153040) [Link]

Why would recursion launch threads? Maybe you were thinking of tasks that exhaust the stack instead?

Dynamically sizing the kernel stack

Posted May 30, 2024 17:26 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Various messaging services that have clients that are mostly idle, for example.

Dynamically sizing the kernel stack

Posted May 31, 2024 10:54 UTC (Fri) by kleptog (subscriber, #1183) [Link] (1 responses)

For example, using Erlang where it is common to have one or more processes per client (eg WhatsApp). These processes are a form of user-space threading though and *very* lightweight. Largely because of the functional nature of the language, no sharing of data between processes and all data being read-only means the stacks can be very small (no registers to be saved/restored) and are allocated on demand. Millions of threads are not unheard of.

But it's running on an interpreter, so can't really be compared with OS level threads in Linux where you're limited by what the hardware can support. If the CPU supported dynamically allocating stack frames when calling a function you'd also be able to get away with much smaller stacks.

Dynamically sizing the kernel stack

Posted May 31, 2024 19:21 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> If the CPU supported dynamically allocating stack frames when calling a function you'd also be able to get away with much smaller stacks.

Golang tried that via segmented stacks. The problem is that switching between segments killed performance. So Go moved to relocatable stacks instead, which is easy for them because (by the language design) pointers can't point to objects on the stack.