Re: Reasoning behind process instead of thread based

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 I agree, a
multi-threaded environment is more demanding in terms of developer
skills and code quality.

But what if I don't write crappy code or if I am prepared to take the
consequences of my bugs, what then? Maybe I really know what I'm doing
and really want to get the absolute best performance out of my server.

> There are clear advantages to separate process space for servers.
> 1. Separate threads can stomp on each other's memory space. (e.g.
> imagine a wild, home-brew C function gone bad).

Not all servers allow home-brewed C functions. And even when they do,
not all home-brewers will write crappy code. This is only a clear
advantage when buggy code is executed.

> 2. Separate processes can have separate user ids, and [hence] different
> rights for file access. A threaded server will have to either be
> started at the level of the highest user who will attach or will have to
> impersonate the users in threads. Impersonation is very difficult to
> make portable.

Yes, this is true and a valid advantage if you ever want access external
and private files. Such access is normally discouraged though, since you
are outside of the boundaries of your transaction.

> 3. Separate processes die when they finish, releasing all resources to
> the operating system. Imagine a threaded server with a teeny-tiny
> memory leak, that stays up 24x7. Eventually, you will start using disk
> for ram, or even use all available disk and simply crash.
>
Sure, but a memory leak is a serious bug and most leaks will have a
negative impact on single threaded systems as well. I'm sure you will
find memory leak examples that are fatal only in a multi-threaded 24x7
environment but they are probably very few overall.

> 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:
1. Threads communicate much faster than processes (applies to locking
and parallel query processing).
2. All threads in a process can share a common set of optimized query plans.
3. All threads can share lots of data cached in memory (static but
frequently accessed tables etc.).
4. In environments built using garbage collection, all threads can share
the same heap of garbage collected data.
5. A multi-threaded system can apply in-memory heuristics for self
adjusting heaps and other optimizations.
6. And lastly, my favorite; a multi-threaded system can be easily
integrated with, and make full use of, a multi-threaded virtual
execution environment such as a Java VM.
...

Regards,
Thomas Hallgren