From: | "Nicolas Bazin" <nbazin(at)ingenico(dot)com(dot)au> |
---|---|
To: | "Jon Franz" <coventry(at)one(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Roadmap for a Win32 port |
Date: | 2002-06-06 00:50:09 |
Message-ID: | 004301c20cf4$1b8d8c10$660d090a@software.ingenico.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)one(dot)net>
To: <pgsql-hackers(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)us>
> To: "Igor Kovalenko" <Igor(dot)Kovalenko(at)motorola(dot)com>
> Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)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(at)candle(dot)pha(dot)pa(dot)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(at)postgresql(dot)org
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-06-06 00:53:15 | Re: Roadmap for a Win32 port |
Previous Message | Neil Conway | 2002-06-06 00:05:44 | Re: Roadmap for a Win32 port |