All the major operating systems should have POSIX threads implemented.
Actually this can be configurable--multithreads or one thread.
Thread-only server is unsafe, I agree. Maybe the following model can be a
little better. Several servers, each is multi-threaded. Every server can
support a maximum number of requests simultaneously. If anything bad
happends, it is limited to that server.
The cons side of processes model is not the startup time. It is about
kernel resource and context-switch cost. Processes consume much more
kernel resource than threads, and have a much higher cost for context
switch. The scalability of threads model is much better than that of
processes model.
-Junfeng
On Mon, 4 Dec 2000, Thomas Lockhart wrote:
> > I am new to postgreSQL. When I read the documents, I find out the Postmaster
> > daemon actual spawns a new backend server process to serve a new client
> > request. Why not use threads instead? Is that just for a historical reason,
> > or some performance/implementation concern?
>
> Both. Not all systems supported by PostgreSQL have a standards-compliant
> threading implementation (even more true for the systems PostgreSQL has
> supported over the years).
>
> But there are performance and reliability considerations too. A
> thread-only server is likely more brittle than a process-per-client
> implementation, since all threads share the same address space.
> Corruption in one server might more easily propagate to other servers.
>
> The time to start a backend is quite often small compared to the time
> required for a complete session, so imho the differences in absolute
> speed are not generally significant.
>
> - Thomas
>
