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.
_____/ _____/ _/ [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
