Conversation

Jun 26, 2021

💯 > In general, it is my opinion that if your program is crashing on Alpine, it is because your program is dependent on behavior that is not guaranteed to actually exist, which means your program is not actually portable

Quote Tweet

Ariadne Conill

@ariadneconill

Jun 25, 2021

understanding thread stack sizes and how alpine is different ariadne.space/2021/06/25/und

Replying to

also glibc sucks for defaulting to giving every thread 8MiB of stack. if you're wondering why alpine is more memory efficient, this is a HUGE part of it

Replying to

and

Wait, isn't that committed on demand? It doesn't actually eat 8 MiB of physical RAM per thread, does it?

Replying to

and

No, but it can use that much so it's accountable memory and requires backing space in memory or swap when memory accounting is enabled. The main thread stack works differently and doesn't actually map all the space at once. It gradually maps it in as the program uses the memory.

4:08 AM · Jun 26, 2021Twitter Web App

Replying to

It means if you want to have reliable main thread stack space under memory exhaustion, you need to touch all of the main thread stack you're going to need later on up front to get it mapped in to the process. Alternatively, you can just not use the main thread after init.

Replying to

You can gradually read it in blocks based on the configured thread gap size to map it in when your process starts and then optionally add your own guard where you want the limit to be since the kernel doesn't necessarily even have a specific limit configured.

Show replies