Re: HEADS UP: Win32/OS2/BeOS native ports

Поиск
Список
Период
Сортировка
От Marc G. Fournier
Тема Re: HEADS UP: Win32/OS2/BeOS native ports
Дата
Msg-id 20020503114846.U97878-100000@mail1.hub.org
обсуждение исходный текст
Ответ на Re: HEADS UP: Win32/OS2/BeOS native ports  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Schemas: status report, call for developers
Следующее
От: mlw
Дата:
Сообщение: Re: HEADS UP: Win32/OS2/BeOS native ports