So... browsers aren't making it easy to use
SharedArrayBuffer--a requirement for the pthreads web build. This is due to something called COOP/COEP. It's making what was already some tough work to turn on threads even tougher:
My ranting response on the topic:
(What I see is a lot of half-baked security theater, where the answer is putting flags on things saying "yes, I meant to use that resource...the one I said to use". You're not able to put this canon list of "I meant to do that" in a nice central location...instead you have to weave the list around piecemeal in various places that express the flag (sometimes in different cases). Then some places just haven't been parameterized to allow the flag, which breaks the whole thing in a frustrating way.)
At one time, the pthreads build was quite a lot faster than the "emterpreter" build. But emterpreter was replaced with the much superior "asyncify" method (if you want to be more specific actually version 2 of it, called "bsyncify"). So right now the performance difference is negligible...and the principal advantage of the pthreads build is that the .wasm generated is less than half the size of the asyncify build.
But if stackless is implemented (which I intend), even asyncify should not be necessary...because we'd be able to unwind our own stack. We wouldn't need asyncify's magical backbone woven into the source that assists in teleporting out-of and back-into any point of the evaluator. So the size difference would go in the reverse direction: pretty much all of the pthreads extra hassle would be make-work, and all those files and code would make it the bigger build.
I'm seriously considering simplifying life and the build/test matrix by dropping the pthreads build. I believed it would be available in all browsers by default, and that part is shaping up to be true. But what I didn't anticipate was the mire of serving concerns that makes it such a hassle--it won't get better, and it may get worse.
Whether it's jsfiddle or any other page where you can't bend every server in the chain to your will...you just couldn't use the pthreads. We're going to need a non-pthreads build. And if we make that the one build that we focus on, deploy, and test...it's just easier.
This isn't to be confused with features related to concurrency...which is something being looked to. But that would be with techniques like "green threading", that don't actually ever have multiple CPU cores potentially competing at a simultaneous moment for the same byte of memory.
For the sake of sanity and ease of deployment, I'm leaning to the idea of killing off the pthreads build. Asyncify changed the game by closing the performance gap, and Stackless will be an even better answer. Let's make life (and testing) easier.
One Lingering Thought...
But this means the Rebol code would not have access to the DOM, and that's not a very interesting working model. (That would be an issue anytime you are trying to run code concurrently...only one thread can access the DOM.)
Then another thing pthreads gives that stackless does not is the ability to "signal" code to wake up, instead of using a polling strategy. That might sound more efficient, but unfortunately a of time when you look under the hood at how these "signals" are implemented actually involves a bunch of timeouts that are isomorphic to polling.
I'm still hedging a bit. What I'll probably do is start ripping out the pthreads code and then pause to reflect if I find anything and think "hmm, that's valuable and would be hard to put back".