Re: [GENERAL] Reasoning behind process instead of thread based

[Neil Conway]

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
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend