Re: Reasoning behind process instead of thread based

I don't see the big difference between what Marco is suggesting and user
threads -- or to be more precise, I think user threads and event-based
programming are just two sides of the same coin. A user thread just
represents the state of a computation -- say, a register context and
some stack. It is exactly that *state* that is passed to a callback
function in the event-based model. The only difference is that with user
threads the system manages context for you, whereas the event-based
model lets the programmer manage it. Which model is better is difficult
to say.

Martijn van Oosterhout wrote:
> 1. non-blocking is nice, but lots of OSes (eg POSIX) don't support it
> on disk I/O unless you use a completely different interface.

We could implement I/O via something like POSIX AIO or a pool of worker
threads that do the actual I/O in a synchronous fashion. But yeah,
either way it's a major change.

> 2. If one of your 'processes' decides to do work for half an hour (say,
> a really big merge sort), you're stuck.

It would be relatively easy to insert yield points into the code to
prevent this from occurring. However, preemptive scheduling would come
in handy when running "foreign" code (e.g. user-defined functions in C).

> I honestly don't think you could really do a much better job of
> scheduling than the kernel.

I think we could do better than the kernel by taking advantage of
domain-specific knowledge, I'm just not sure we could beat the kernel by
enough to make this worth doing.

BTW, I think this thread is really interesting -- certainly more
informative than a rehash of the usual "processes vs. threads" debate.

-Neil