Re: Roadmap for a Win32 port - Mailing list pgsql-hackers

Gnu Pth also supports AIO
----- Original Message -----
From: "Nicolas Bazin" <nbazin@ingenico.com.au>
To: "Jon Franz" <coventry@one.net>; <pgsql-hackers@postgresql.org>
Sent: Thursday, June 06, 2002 10:50 AM
Subject: Re: [HACKERS] Roadmap for a Win32 port


> 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
> >
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>