[Cc: list minimized]
On Tue, 2 Nov 2004, Neil Conway wrote:
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
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
On Thu, 28 Oct 2004, Thomas Hallgren wrote:
Marco,
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.
You need to clarify this a bit.
You say that the scheduler is in user-space, yet there's only one thread per
proces
Marco,
You ask what an event is? An event can be:
- input from a connection (usually a new query);
- notification that I/O needed by a pending query has completed;
- if we don't want a single query starve the server, an alarm of kind
(I think this is a corner case, but still possible;)
- somethin
Martijn,
I honestly don't think you could really do a much better job of
scheduling than the kernel. The kernel has a much better idea of what
processes are waiting on, and more importantly, what other work is
happening on the same machine that also needs CPU time.
>
I agree 100% with Martijn. Belo
On Thu, Oct 28, 2004 at 04:32:34PM +0200, Marco Colombo wrote:
> On Thu, 28 Oct 2004 [EMAIL PROTECTED] wrote:
>
> >
> >Marco,
> >
> >Wouldn't locking a process to a CPU cause the CPU to be idle during IO
> >waits and semaphore locks? Even if you didn't lock each DB process to a
> >CPU, IO waits a
Marco,
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.
You need to clarify this a bit.
You say that the scheduler is in user-space, yet there's only one thread
per process and one process per CPU. You state that in
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 fo
On Thu, 28 Oct 2004 [EMAIL PROTECTED] wrote:
Marco,
Wouldn't locking a process to a CPU cause the CPU to be idle during IO
waits and semaphore locks? Even if you didn't lock each DB process to a
CPU, IO waits and locks for one session would stop processing on other
sessions managed by the same pro
[EMAIL PROTECTED] writes:
>>Two: If a
>> single process in a multi-process application crashes, that process
>> alone dies. The buffer is flushed, and all the other child processes
>> continue happily along. In a multi-threaded environment, when one
>> thread dies, they all die.
>
> So this mean
On Thu, Oct 28, 2004 at 02:44:55PM +0200, Marco Colombo wrote:
> 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 sessio
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
[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 ver
Martijn van Oosterhout wrote:
Now you've piqued my curiosity. You have two threads of control (either
two processes or two threads) which shared a peice of memory. How can
the threads syncronise easier than processes, what other feature is
there? AFAIK the futexes used by Linux threads is just as a
[EMAIL PROTECTED] wrote:
So Thomas, you say you like the PostgreSQL process based modell better
than the threaded one used by MySQL. But you sound like the opposite. I'd
like to know why you like processes more.
Ok, let me try and explain why I can be perceived as a scatterbrain :-).
PostgreSQL
On Thu, Oct 28, 2004 at 12:13:41AM +0200, Thomas Hallgren wrote:
> Martijn van Oosterhout wrote:
> >A lot of these advantages are due to sharing an address space, right?
> >Well, the processes in PostgreSQL share address space, just not *all*
> >of it. They communicate via this shared memory.
> >
>
Tom Lane wrote:
That argument has zilch to do with the question at hand. If you use a
coding style in which these things should be considered recoverable
errors, then setting up a signal handler to recover from them works
about the same whether the process is multi-threaded or not. The point
I wa
Thomas Hallgren <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Right. Depending on your OS you may be able to catch a signal that
>> would kill a thread and keep it from killing the whole process, but
>> this still leaves you with a process memory space that may or may not
>> be corrupted.
> It
Tom Lane wrote:
Right. Depending on your OS you may be able to catch a signal that
would kill a thread and keep it from killing the whole process, but
this still leaves you with a process memory space that may or may not
be corrupted. Continuing in that situation is not cool, at least not
accordi
Martijn van Oosterhout wrote:
A lot of these advantages are due to sharing an address space, right?
Well, the processes in PostgreSQL share address space, just not *all*
of it. They communicate via this shared memory.
Whitch is a different beast altogether. The inter-process mutex handling
that yo
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> ... Signals are shared between threads. Now, you could ofcourse catch
> these signals but you only have one address space shared between all
> the threads, so if you want to exit to get a new process image (because
> something is corrupted), you
On Wed, Oct 27, 2004 at 10:07:48PM +0200, Thomas Hallgren wrote:
> >Threaded servers have one main advantate:
> >Threads are lightweight processes and starting a new thread is faster
> >than starting a new executable.
> >
> A few more from the top of my head:
A lot of these advantages are due to s
On Wed, Oct 27, 2004 at 05:56:16PM +0200, [EMAIL PROTECTED] wrote:
>
> I understand PostgreSQL uses processes rather than threads. I found this
> statement in the archives:
>
> "The developers agree that multiple processes provide
> more benefits (mostly in stability and robustness) than costs (m
Dann,
I'm not advocating a multi-threaded PostgreSQL server (been there, done
that :-). But I still must come to the defense of multi-threaded systems
in general.
You try to convince us that a single threaded system is better because
it is more tolerant to buggy code. That argument is valid and
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Thomas Hallgren
> Sent: Wednesday, October 27, 2004 11:16 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [GENERAL] Reasoning behind process instead of
> thread based
>
&
[EMAIL PROTECTED] wrote:
Two: If a
single process in a multi-process application crashes, that process
alone dies. The buffer is flushed, and all the other child processes
continue happily along. In a multi-threaded environment, when one
thread dies, they all die.
So this means that if a single
On Wed, Oct 27, 2004 at 07:47:03PM +0200, [EMAIL PROTECTED] wrote:
> >Two: If a
> > single process in a multi-process application crashes, that process
> > alone dies. The buffer is flushed, and all the other child processes
> > continue happily along. In a multi-threaded environment, when one
>
>Two: If a
> single process in a multi-process application crashes, that process
> alone dies. The buffer is flushed, and all the other child processes
> continue happily along. In a multi-threaded environment, when one
> thread dies, they all die.
So this means that if a single connection thr
On some operating systems, like Windows and Solaris, processes are
expensive, while threads are cheap, so to speak. this is not the case
in Linux or BSD, where the differences are much smaller, and the
multi-process design suffers no great disadvantage.
Even on Windows or Solaris you can use techn
On Wed, 2004-10-27 at 09:56, [EMAIL PROTECTED] wrote:
> Hello!
>
> I have a couple of final ( I hope, for your sake ) questions regarding
> PostgreSQL.
>
> I understand PostgreSQL uses processes rather than threads. I found this
> statement in the archives:
>
> "The developers agree that multipl
[EMAIL PROTECTED] writes:
> "The developers agree that multiple processes provide
> more benefits (mostly in stability and robustness) than costs (more
> connection startup costs). The startup costs are easily overcome by
> using connection pooling.
> "
>
> Please explain why it is more stable and
Hello!
I have a couple of final ( I hope, for your sake ) questions regarding
PostgreSQL.
I understand PostgreSQL uses processes rather than threads. I found this
statement in the archives:
"The developers agree that multiple processes provide
more benefits (mostly in stability and robustness) t
32 matches
Mail list logo
