Re: Roadmap for a Win32 port - Mailing list pgsql-hackers
From | Nicolas Bazin |
---|---|
Subject | Re: Roadmap for a Win32 port |
Date | |
Msg-id | 004301c20cf4$1b8d8c10$660d090a@software.ingenico.com.au Whole thread Raw |
In response to | Re: Roadmap for a Win32 port (Bruce Momjian <pgman@candle.pha.pa.us>) |
List | pgsql-hackers |
Yes I proposed to use the GNU Pth library instead. It's an event demultiplexer just like the sgi library, but has a posix thread interface. This architecture is actually the more robust and also the more scalable. On a single processor server, you don't have the multi-thread synchronization and context switching overhead and you also take full advantage of multi-processor servers when you create several processes. Plus you have much less concern about global variables. Also for those concerned about the licence of this library here is an abstract of it: "The author places this library under the LGPL to make sure that it can be used both commercially and non-commercially provided that modifications to the code base are always donated back to the official code base under the same license conditions. Please keep in mind that especially using this library in code not staying under the GPL or the LGPL _is_ allowed and that any taint or license creap into code that uses the library is not the authors intention. It is just the case that _including_ this library into the source tree of other applications is a little bit more inconvinient because of the LGPL. But it has to be this way for good reasons. And keep in mind that inconvinient doesn't mean not allowed or even impossible." So it can be used in both commercial and non commercial project. ----- Original Message ----- From: "Jon Franz" <coventry@one.net> To: <pgsql-hackers@postgresql.org> Sent: Thursday, June 06, 2002 8:50 AM Subject: Re: [HACKERS] Roadmap for a Win32 port > One note: SGI developers discovered they could get amazing performance using > as hybrid threaded and forked-process model with apache - we might want to > look into this. They even have a library for network-communication > utilizing thier 'state threads' model. Please see: > > http://state-threads.sourceforge.net/docs/st.html > > Thus, on platforms where it can be supported, we should keep in mind that a > hybrid multiprocess/multithreaded postgresql might be the fastest > solution... > > > ----- Original Message ----- > From: "Bruce Momjian" <pgman@candle.pha.pa.us> > To: "Igor Kovalenko" <Igor.Kovalenko@motorola.com> > Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org> > Sent: Wednesday, June 05, 2002 4:05 PM > Subject: Re: [HACKERS] Roadmap for a Win32 port > > > > Igor Kovalenko wrote: > > > I might be naive here, but would not proper threading model remove the > need > > > for fork() altogether? On both Unix and Win32? Should not be too hard to > > > come up with abstraction which encapsulates POSIX, BeOS and Win32 > threads... > > > I am not sure how universal POSIX threads are by now. Any important Unix > > > platforms which don't support them yet? > > > > > > This has downside of letting any bug to kill the whole thing. On the > bright > > > side, performance should be better on some platforms (note however, > Apache > > > group still can't come up with implementation of threaded model which > would > > > provide better performance than forked or other models). The need to > deal > > > with possibility of 'alien' postmaster running along with orphaned > backends > > > would also be removed since there would be only one process. > > > > > > Issue of thread safety of code will come up undoubtedly and some things > will > > > probably have to be revamped. But in long term this is probably best way > if > > > you want to have efficient and uniform Unix AND Win32 implementations. > > > > > > I am not too familiar with Win32. Speaking about POSIX threads, it would > be > > > something like a thread pool with low & high watermarks. Main thread > would > > > handle thread pool and hand over requests to worker threads (blocked on > > > condvar). How does that sound? > > > > 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. > > > > -- > > Bruce Momjian | http://candle.pha.pa.us > > pgman@candle.pha.pa.us | (610) 853-3000 > > + If your life is a hard drive, | 830 Blythe Avenue > > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > >
pgsql-hackers by date: