Re: Reasoning behind process instead of thread based

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