I'm not sure what roadmap you are talking about. Threads are actually removed from WASI Preview 2.
WASI Preview 2 still doesn't support threads, fork, subprocesses or longjmp/setjmp (among others). Not even that, when WASIX was created not even sockets were supported in WASI.
I'd recommend trying to compile bash or curl to WASI Preview 2 and WASIX and see how far you get in each before trying to polarize the readers between WASI Preview 2 and WASIX.
The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt.
Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.
If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I think that's great. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime with the strongest long-term outlook), nor will it run in browsers, because they're going to follow standards.. not WASIX. I don't think anyone believes exposing POSIX fork() to WASM is a good idea, even if it lets you build existing apps 'without modification'.
Please stop accusing me of being polarizing. I just don't want to live in a world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall. I want good tech to win, not shitty power plays.
Just to be clear, and to reinforce what I mentioned.
WASI Preview 2 doesn't officially support threads. There are some ways to get it running as you mentioned, but threads are NOT part of WASI Preview 2. Which is what you initially stated and I corrected.
We don't want to have competing standards either, and we'd love to merge things upstream. However, based on my interactions with the WASI subgroup it seems clear they want to keep some of this things that WASIX needs out of the spec (and that's ok!). If you would not like to have that, then you shall probably direct your requests towards them, not us.
> I want good tech to win
Me too! I now understand this over-idealistic belief is the root of the issue.
Good tech doesn't win, a good product does.
So, in light of that, what is the reason for diverging from WASI and creating WASIX?