Re: Reasoning behind process instead of thread based

On Thu, 28 Oct 2004, Thomas Hallgren wrote:

> 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.

See the "if the OS is good enough" part... :-)

AFAIK, many techniques developed under Linux have been included in
recent releases of other OSes. I haven't seen the source, of course.

If recent Solaris still has processes which are actually "heavy", well
I call that "an old legacy (mis-)feature on a modern and reasonable OS"...
Back in '93, Mr. Gates used to state: "NT is Unix". If it's not the case
yet, well, it's not _my_ fault.

>> 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

No. I just meant "scheduling" between PG sessions. I'm not interested in
userspace threads. Those are general purpose solutions, with the drawbacks
you pointed out.

I mean an entirely event driven server. The trickiest part is to handle
N-way. On 1-way, it's quite a clear and well-defined model.

I'm not going to say it's easy. I'd like to move the discussion away from
the sterile processes vs threads issue. Most differences there are
platform specific anyway. The model is the same: one thread of execution
per session. I'm proposing a new model entirely (well I'm proposing
a _discussion_ on a model vs. model basis and not implementation vs
implementation of the same model).

If you read this thread, you'll notice most people miss the point:
either processes or threads, the model is the same, many many actors
that share a big part of their memory. The problems are the same, too.
Should we buy the fact that processes are safer? Of course, it's not the
case, when they share such a big memory segment. The chance of a runaway
pointer thrashing some important shared data is almost the same for both
processes and threads. If one backend crashes for a SIGSEGV, I'd bet
nothing on the shared mem not being corrupted somehow.

My point being: how about [discussing of] a completely different model
instead?

.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo(at)ESI(dot)it