Remove unused element from pthread struct. NFC

[sbc100]

This reduces the memory overhead of a pthread from 124 bytes to 100 bytes (~20%) saving.

This change was created mostly by Gemini CLI.

[kripken]

Is this worth increasing the diff vs. musl? Generally there are not many pthreads, so we are talking dozens of bytes, maybe hundreds?

[sbc100]

Is this worth increasing the diff vs. musl? Generally there are not many pthreads, so we are talking dozens of bytes, maybe hundreds?

I was kind of hoping we could add this struct to the TLS area of Wasm Workers.. so that wasm workers could use pthread_mutex_lock etc. I imagined that @juj would like this to be as small as possible to avoid growing the size of the wasm worker allocations, but maybe ~50 bytes per works is not significant?

[juj]

I imagined that @juj would like this to be as small as possible to avoid growing the size of the wasm worker allocations

Thanks for thinking out, very much appreciated.

In general with Wasm Workers and MINIMAL_RUNTIME, the big interest we have is in optimizing disk size. The runtime memory usage on the other hand does not need to be shaved to be byte optimal (as long as we are not like +hundreds of KBs lax for little benefit). That is:

• in general, if there's a tradeoff between smaller disk size vs smaller runtime memory usage, practically always lean towards smaller disk size, and
• having a uniform code with upstream musl is probably more appealing than optimizing for runtime bytes here.

The main tricky part here is probably in how to get the thread ID TLS for Wasm Workers to only take place if the user is actually using pthread mutexes.

I.e. if Wasm Workers -only users will have to pay for code size related to pthreads, if they are not using any of the pthread mutex API.. that would be unfortunate.

[sbc100]

I.e. if Wasm Workers -only users will have to pay for code size related to pthreads, if they are not using any of the pthread mutex API.. that would be unfortunate.

Would the following outcome seem reasonable / acceptable:

1. Pure WASM_WORKERS builds don't have any per-thread memory overhead
2. If you build with WASM_WORKERS + pthreads in the same build you pay the normal ~100 byte overhead for each pthread and each wasm worker.

In scenario two is almost certain that the build uses pthread APIs so the overhead is expected in that case right?

This would allow is to plug a pretty big hole that exists today with scenario (2) which is that calling any pthread function from a wasm workers is just undefined behaviour. (Scenario (1) doesn't have this problem because its no longer possible to call any pthread functions at in this configuration).

[juj]

Pure WASM_WORKERS builds don't have any per-thread memory overhead

If you build with WASM_WORKERS + pthreads in the same build you pay the normal ~100 byte overhead for each pthread and each wasm worker.

Yeah, this would be the best outcome I think. Then WASM_WORKERS users who would like to use pthread API with WASM_WORKERS could build with -pthread -sWASM_WORKERS, and users who want to steer clear from the POSIX API bits could run with -sWASM_WORKERS.

I suppose if we don't link to the pthread functions at all in just -sWASM_WORKERS mode, we could then build the pthread parts to always assume that the pthread id block always exists, so that the code size inrease will stay conditional to only when targeting -pthread...?

[sbc100]

I suppose if we don't link to the pthread functions at all in just -sWASM_WORKERS mode, we could then build the pthread parts to always assume that the pthread id block always exists, so that the code size inrease will stay conditional to only when targeting -pthread...?

Yes, exactly.

In fact that is already exactly what appends today. In the hybrid mode if you do call pretty much any pthread function from a Wasm Worker it will do looks like __pthread_self()->my_field which will return the my_field at an offset from the NULL pointer, which happens to not crash .. which is bad.

[sbc100]

We should either make it work or inject some kind of assertion in into __pthread_self() when built in hybrid mode.