Re: Reasoning behind process instead of thread based

From: Marco Colombo <marco(at)esi(dot)it>
To: Richard_D_Levine(at)raytheon(dot)com
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Reasoning behind process instead of thread based
Date: 2004-10-28 14:32:34
Message-ID: Pine.LNX.4.61.0410281601340.29788@Megathlon.ESI
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 28 Oct 2004 Richard_D_Levine(at)raytheon(dot)com 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 process. Moving the scheduler to user space
> seems to be reimplementing something the kernel knows best about. Ever
> worked with Ada tasking architectures? Not pretty.

Quick answers:
- there won't be any I/O wait;
- there won't be any semaphore-related wait;
- in my previous message, I've never mentioned the kernel scheduler;
- no, the kernel knows nothing about PostgreSQL sessions.

It seems quite obvious to me that in the "one flow of execution per CPU"
model, all I/O is non-blocking. Everything is event-driven.

With session "scheduler" I was referring to the (generic) operation
of serving multiple sessions. On a 1-way system we do want to serve more
than one client. Right now, we relay on the kernel in choosing which one
to run at a given moment. We _do_ know better of it in many cases, see
the priority inversion problem mentioned a few days ago on the list.

The above is true for most N-ways systems, since we still want to serve
M sessions, where usually M >> N.

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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Andrew Sullivan 2004-10-28 14:37:02 Re: compatibilityissues from 7.1 to 7.4
Previous Message Sally Sally 2004-10-28 14:31:32 Re: primary key and existing unique fields