Re: Reasoning behind process instead of thread based

On Thu, 28 Oct 2004 Richard_D_Levine@raytheon.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@ESI.it