Don't have much to say on the topic but recalled this excerpt from the book Coders at Work in the chapter interviewing Douglas Crockford.
``` In my experience, the worst bugs are the real-time bugs, which have to do with interactions with multiple threads. My approach to those bugs is to avoid making them. So I don't like threads. I think threads are an atrocious programming model. They're an occasionally necessarily evil, but they're not necessary for most of the things we use threads for.
One of the things I like about the browser model is that we only get one thread. Some people complain about that—if you lock up that thread, then the browser's locked up. So you just don't do that. There are constantly calls for putting threads into JavaScript and so far we've resisted that. I'm really glad we have.
The event-based model, which is what we're using in the browser, works really well. The only place where it breaks down is if you have some process that takes too long. I really like the approach that Google has taken in Gears to solving that, where they have a separate process which is completely isolated that you can send a program to and it'll run there. When it's finished, it'll tell you the result and the result comes back as an event. That's a brilliant model. ```
Soo... Essentially, still threads, but no shared state between threads, and they talk through this message interface?
Threads which can’t share state are called processes.
Fair-ish point, if a bit cheeky. But threads can be still threads, i.e. in the same address space, but without actually having shared state between them. And then they're still threads, not processes.
You could also have stuff like message ques going between them, the cost of passing data around is small then, you don't have do leave user space to put stuff in the mq's. But can you still call it "not having shared state"? I'd say yes, even though you do share memory and you do have the mutually accessible que. But I can see why you could argue otherwise.
> Fair-ish point, if a bit cheeky. But threads can be still threads, i.e. in the same address space, but without actually having shared state between them. And then they're still threads, not processes.
If they don’t share state implicitly, then by all relevant features they are processes. That they share an address space is not really relevant except as an opportunity for optimisation. See BEAM.
Hell, older consumer OS used to not have memory isolation, even after multitasking was introduced.
this is why operating systems have forbidden threads since 1999 and no one has ever used them since.