Re: Reasoning behind process instead of thread based

On Thu, Oct 28, 2004 at 04:32:34PM +0200, Marco Colombo wrote:
> 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.

Ok, let me think here. I think what you are suggesting is like the way
IRC servers work. They have one process with a few thousand sockets and
simply process the messages as they come in.

Only you want to do it in a system that actually needs to do a lot of
processing. Basically, you'd need to make all I/O non-blocking and all
the code would probably need to be converted to callback routines or
something similar. If you have no global variables this is quite
doable, though of questionable benefit. The issues I can think of:

1. non-blocking is nice, but lots of OSes (eg POSIX) don't support it
on disk I/O unless you use a completely different interface.

2. If one of your 'processes' decides to do work for half an hour (say,
a really big merge sort), you're stuck. At least with multiple
processes the kernel will preempt you eventually.

3. On Linux anyway, most process scheduling occurs on I/O waits anyway.
Forcable preemption can only really occur up to 100 times per second
and unless someone else is available to run (ie not I/O wait) nothing
will change.

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.
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.