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
likeUSE_DARWIN_SEMAPHORES=1SEMA_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
