Re: Threaded PosgreSQL server - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: Threaded PosgreSQL server
Date
Msg-id 20020205153107.S44048-100000@earth.hub.org
Whole thread Raw
In response to Re: Threaded PosgreSQL server  (Haroldo Stenger <hstenger@adinet.com.uy>)
Responses Re: Threaded PosgreSQL server  (<mkscott@sacadia.com>)
Re: Threaded PosgreSQL server  (Jean-Michel POURE <jm.poure@freesurf.fr>)
Re: Threaded PosgreSQL server  (nconway@klamath.dyndns.org (Neil Conway))
List pgsql-hackers
On Tue, 5 Feb 2002, Haroldo Stenger wrote:

> Dann Corbit wrote:
> >
> > Are there any plans to merge the sources from the experimental threaded
> > server and the forked server so that a compile switch could choose the
> > model?
>
> Just a question, in order to elighten my thought. Does the current experimental
> threaded server disable multi-process model? Or does it *add* the functionality
> as a compile switch? (This would be the other way round as the one you pointed
> out.)
>
> I think it is important as to evaluate resistance to go multithreading.
>
> If they disabled the original method, I agree with Tom. If they *merged* both
> flawlessly, I would try to consider it for the current tree.
>
> Any comments?

That's kinda what I was hoping ... is it something that could be
seamlessly integrated to have minimal impact on the code itself ... even
if there was some way of having a 'thread.c' vs 'non-thread.c' that could
be link'd in, with wrapper functions?

Tha again, has anyone looked at the apache project?  Apache2 has several
"process models" ... prefork being one (like ours), or a 'worker', which
is a prefork/threaded model where you can have n child processes, with m
'threads' inside of each ... not sure if something like that coul be
retrofit'd into what we have, but ... ?



pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: Management tool support and scalibility
Next
From: Brian Bruns
Date:
Subject: Re: DRDA, network protocol, and documentation