Re: Reasoning behind process instead of thread based

Marco Colombo wrote:
> [processes vs threads stuff deleted]
>
> In any modern and reasonable Unix-like OS, there's very little difference
> between the multi-process or the multi-thread model. _Default_ behaviour
> is different, e.g. memory is shared by default for threads, but processes
> can share memory as well. There are very few features threads have
> that processes don't, and vice versa. And if the OS is good enough,
> there are hardly performance issues.
>
Most servers have a desire to run on Windows-NT and I would consider
Solaris a "modern and reasonable Unix-like OS". On both, you will find a
significant performance difference. I think that's true for Irix as
well. Your statement is very true for Linux based OS'es though.

> I think that it would be interesting to discuss multi(processes/threades)
> model vs mono (process/thread). Mono as in _one_ single process/thread
> per CPU, not one per session. That is, moving all the "scheduling"
> between sessions entirely to userspace. The server gains almost complete
> control over the data structures allocated per session, and the resources
> allocated _to_ sessions.
>
I think what you mean is user space threads. In the Java community known
as "green" threads, Windows call it "fibers". That approach has been
more or less abandoned by Sun, BEA, and other Java VM manufacturers
since a user space scheduler is confined to one CPU, one process, and
unable to balance the scheduling with other processes and their threads.
A kernel scheduler might be slightly heavier but it does a much better job.

Regards,
Thomas Hallgren