Re: Reasoning behind process instead of thread based - Mailing list pgsql-general

From Marco Colombo
Subject Re: Reasoning behind process instead of thread based
Date
Msg-id Pine.LNX.4.61.0410281139180.29788@Megathlon.ESI
Whole thread Raw
In response to Re: Reasoning behind process instead of thread based  (Thomas Hallgren <thhal@mailblocks.com>)
Responses Re: Reasoning behind process instead of thread based  (Thomas Hallgren <thhal@mailblocks.com>)
Re: Reasoning behind process instead of thread based  ("Jim C. Nasby" <decibel@decibel.org>)
List pgsql-general
[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.

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 bet this is very theoretical since it'd require a complete redesign
of some core stuff. And I have strong concerns about portability.  Still,
it could be interesting.

.TM.
--
       ____/  ____/   /
      /      /       /            Marco Colombo
     ___/  ___  /   /              Technical Manager
    /          /   /             ESI s.r.l.
  _____/ _____/  _/               Colombo@ESI.it

pgsql-general by date:

Previous
From: Thomas Hallgren
Date:
Subject: Re: Reasoning behind process instead of thread based
Next
From: Gaetano Mendola
Date:
Subject: Re: '1 year' = '360 days' ????