Re: HEADS UP: Win32/OS2/BeOS native ports - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: HEADS UP: Win32/OS2/BeOS native ports
Date
Msg-id 20020503114846.U97878-100000@mail1.hub.org
Whole thread Raw
In response to Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 3 May 2002, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
> > All I'm planning on doing is changing the appropriate shm_* functions iwth
> > pg_shm_* functions ... if !(libapr), all those pg_shm_* functions will
> > have in them is the original call we've always used ... there will even be
> > a --disable-libapr configure option so that if someone already has Apache2
> > installed, but doesn't wanna use libapr for PgSQL, they don't have to ...
>
> > Basically, all I'm looking at is allowing PgSQL to use a different library
> > for its shared memory calls then the standard one, nothing else ...
>
> Oh.  I guess my next question is how closely that Apache library
> emulates the SysV shmem semantics.  In particular, can you reliably
> tell how many processes are attached to a shmem block?  (Cf
> SharedMemoryIsInUse() in storage/ipc/ipc.c)  Without that feature we
> have an interlock problem.

Will investigate this ... my immediate goal is to just get it so that an
alternate library can be used ... default behaviour will be to stick with
our current function calls ... to use libapr, you will/would have to use a
configure option for it (sorry, meant --enable above, not --disable) ...

The only '#ifdef's I'm planning on for this will be in a central shmem.*
file(s), so there isn't going to be a string of those all over the place
or anything stupid like that ...



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Schemas: status report, call for developers
Next
From: mlw
Date:
Subject: Re: HEADS UP: Win32/OS2/BeOS native ports