Sam Clegg

I really like the fact the folks have to opt into `_WASI_EMULATED_MMAN`. It makes it fairly clear that its a non-optimal path.

I don't see any reference to `O_RESOLVE_BENEATH` in musl, or indeed anywhere on my linux system. Are you sure its part of POSIX? It doesn't seem to be part of...

I think for files that come from upstream musl its best to stick to the upstream style of the musl codebase. I doubt this style is covered by a pre-existing...

The GNU style might be a good starting point: https://clang.llvm.org/docs/ClangFormatStyleOptions.html#basedonstyle ?

> Yeah, I'd be interested in seeing what happens if we apply that... I don't think we want to be applying that to existing code, since we are mostly a...

Yes we probably want to make sure `USE_SPIN_LOCKS` is not defined, so it will fallback to pthread locks.

Here is where emscripten does that: https://github.com/emscripten-core/emscripten/blob/e64e3701c9c6d9fc2622fb34b92065971c326ed1/system/lib/dlmalloc.c#L29-L32

As far as I can tell `pthread_mutex_lock` uses `__wasilibc_futex_wait` just like `__wait`. Its just a rather indirect path: `pthread_mutex_lock` -> `__pthread_mutex_timedlock` `__pthread_mutex_timedlock` -> `__timedwait` `__timedwait` -> `__timedwait_cp` `__timedwait_cp` -> `__futex4_cp`...

> > I don't think that's exclusive to proposed changes here? I'd assume the userspace code would have to somehow set stack boundaries (as it's the one that allocates memory...

I know you mention some rational in #322, but I'm curious what you personal primary motivation is for wanting to make this change? I guess better native windows support is...