> If wasm adopts threads that would be another unfortunate WorseIsBetter situation, given that threads are probably the worst model of concurrency we've ever devised (other than concurrent COMEFROM)!
Like it or not, threads are here to stay. Threads with shared mutable memory are the abstraction that multi-processor systems give software. They are not a software invention (anymore, as they might have been considered in the uniprocessor era).
A key goal of Wasm is to be a portable (and safe!) abstraction over hardware. Thus exposing extremely pervasive hardware abstractions like threads is well within its mission. Doing so safely has meant careful design and specification that captures what hardware gives for memory models without forcing a new programming model or undue burden on languages, toolchains, or runtimes.
Given that there are literally billions of lines of software that use threads, hardware actually implements threads, and the entire stack is driven to optimize threads, it would indeed be a bold move to impose a different abstraction at the Wasm level. An abstraction that would incidentally be immediately used to emulate threads. That's a real layering screwup--abstraction inversion.
Also, I think your pedantry is unwarranted and a distraction. Many people accept the claim that threads are "true parallelism" and would consider cooperative (or even green) threading systems to be "not what we meant when we said threads". It's just a red herring to go off and discuss technicalities when the context is clearly Wasm exposing hardware threads.
Like it or not, threads are here to stay. Threads with shared mutable memory are the abstraction that multi-processor systems give software. They are not a software invention (anymore, as they might have been considered in the uniprocessor era).
A key goal of Wasm is to be a portable (and safe!) abstraction over hardware. Thus exposing extremely pervasive hardware abstractions like threads is well within its mission. Doing so safely has meant careful design and specification that captures what hardware gives for memory models without forcing a new programming model or undue burden on languages, toolchains, or runtimes.
Given that there are literally billions of lines of software that use threads, hardware actually implements threads, and the entire stack is driven to optimize threads, it would indeed be a bold move to impose a different abstraction at the Wasm level. An abstraction that would incidentally be immediately used to emulate threads. That's a real layering screwup--abstraction inversion.
Also, I think your pedantry is unwarranted and a distraction. Many people accept the claim that threads are "true parallelism" and would consider cooperative (or even green) threading systems to be "not what we meant when we said threads". It's just a red herring to go off and discuss technicalities when the context is clearly Wasm exposing hardware threads.