> -----Original Message-----
> From: Thomas Lockhart [mailto:thomas@fourpalms.org]
> Sent: Wednesday, June 05, 2002 3:03 PM
> To: Bruce Momjian
> Cc: Igor Kovalenko; PostgreSQL-development
> Subject: Re: [HACKERS] Roadmap for a Win32 port
>
>
> ...
> > Good summary. I think we would support both threaded and fork()
> > operation, and users can control which they prefer. For a
> web backend
> > where many sessions are a single query, people may want to
> give up the
> > stability of fork() and go with threads, even on Unix.
>
> I would think that we would build on our strengths of having
> a fork/exec
> model for separate clients. A threaded model *could* benefit
> individual
> clients who are doing queries on multiprocessor servers, and
> I would be
> supportive of efforts to enable that.
>
> But the requirements for that may be less severe than for managing
> multiple clients within the same process, and imho there is not strong
> requirement to enable the latter for our current crop of well
> supported
> targets. If it came for free then great, but if it came with
> a high cost
> then the choice is not as obvious. It is also not a
> *requirement* if we
> were instead able to do the multiple threads for a single client
> scenerio first.
Notion:
Have one version do both. Your server can fork(), and your sever can
thread. It can fork() and thread, it can fork() or thread.
That gives the best of all worlds. One client who has his attachments
to a database all setup might want to do a bunch of similar queries.
Hence a threaded model is nice.
A server may be set up to clone the rights of the attaching process for
security reasons. Then you launch a new server with fork().
