Re: Native Windows, Apache Portable Runtime - Mailing list pgsql-hackers
From | Marc G. Fournier |
---|---|
Subject | Re: Native Windows, Apache Portable Runtime |
Date | |
Msg-id | 20020506004243.Y32524-100000@mail1.hub.org Whole thread Raw |
In response to | Re: Native Windows, Apache Portable Runtime (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Native Windows, Apache Portable Runtime
|
List | pgsql-hackers |
Well, I guess that just saved *me* alot of work ... thanks ... On Sat, 4 May 2002, Tom Lane wrote: > mlw <markw@mohawksoft.com> writes: > > We could provide a PGSemaphore based on an APR mutex and a counter, > > but I'm not sure of the performance impact. We may want to implement a > > "generic" semaphore like this and one optimized for platforms which we > > have development resources. > > Once we have the internal API redone, it should be fairly easy to > experiment with alternatives like that. > > I'm planning to work on this today (need a break from thinking about > schemas ;-)). I'll run with the API I sketched yesterday, since no one > objected. Although I'm not planning on doing anything to the API of the > shared-mem routines, I'll break them out into a replaceable file as > well, just in case anyone wants to try a non-SysV implementation. > What I plan to do is: > > 1. Replace include/storage/ipc.h with "pg_sema.h" and "pg_shmem.h" > containing the hopefully-platform-independent API definitions, plus > ifdef'd sections along the lines of > > #ifdef USE_SYSV_SEMAPHORES > > typedef struct PGSemaphoreData { > int id; > int num; > } PGSemaphoreData; > > typedef PGSemaphoreData *PGSemaphore; > > #endif > > AFAICS at the moment, only this typedef needs to vary across different > implementations as far as the header is concerned. > > 2. Break out the SysV-dependent code into backend/port/sysv_sema.c > and backend/port/sysv_shmem.c. storage/ipc/ipc.c will either go away > completely or get lots smaller. > > 3. Extend configure to define the correct USE_foo_SEMAPHORES symbol > in pg_config.h, and to symlink the correct implementation files to > backend/port/pg_sema.c and backend/port/pg_shmem.c. These two "files" > will be the ones compiled and linked into the backend. > > I'm expecting that configure will default to use SysV semas and shared > memory unless told differently by the "template" script selected for > the platform. For instance src/template/darwin might contain something > like > USE_DARWIN_SEMAPHORES=1 > SEMA_IMPLEMENTATION=src/backend/port/darwin/sem.c > to override the default semaphore implementation. Later we might want > some more-dynamic way of configuring the sema type, but this seems like > enough to get started. > > Comments, better ideas? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org >
pgsql-hackers by date: