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

mlw <markw@mohawksoft.com> writes:
> I am writing a Win32 DLL implementation of :

> int     semget(key_t key, int nsems, int semflg);
> int     semctl(int semid, int semnum, int cmd, union semun arg);
> int     semop(int semid, struct sembuf * sops, unsigned nsops);

Rather than propagating the SysV semaphore API still further, why don't
we kill it now?  (I'm willing to keep the shmem API, however.)

After looking over the uses of these functions, I believe that we could
easily develop a non-SysV-centric internal API.  Here's a first cut:

1.  Define a struct type PGSemaphore that has implementation-specific
contents (the generic code will never look inside it).  Operations on
semaphores will take "PGSemaphore *" arguments.  When implementing atop
SysV semaphores, PGSemaphore will contain two fields, the semaphore id
and semaphore number.  In other cases the contents could be different.

2.  All PGSemaphore structs will be physically stored in shared memory.
This doesn't matter for SysV support, where the id/number are constants
anyway; but it will allow implementations based on mutexes.

3.  The operations needed are

* Reserve semaphores.  This will be told the number of semaphores
needed.  On SysV it will do the necessary semget()s, but on some
implementations it might be a no-op.  This should also be prepared
to clean up after a failed postmaster, if it is possible for sema
resources to outlive the creating postmaster.

* Create semaphore.  Given a pointer to an uninitialized PGSemaphore
struct, initialize it to a new semaphore with count 1.  (On SysV this
would hand out the individual semas previously allocated by Reserve.)
Note that this is not responsible for allocating the memory occupied
by the PGSemaphore struct --- I envision the structs being part of
larger objects such as PROC structures.

* Release semaphores.  Release all resources allocated by previous
Reserve and Create operations.  This is called when shutting down
or when resetting shared memory after a backend crash.

* Reset semaphore.  Reset an existing PGSemaphore to count zero.

* Lock semaphore.  Identical to current IpcSemaphoreLock(), except
parameter is a PGSemaphore *.  See code of that routine for detailed
semantics.

* Unlock semaphore.  Identical to current IpcSemaphoreUnlock(), except
parameter is a PGSemaphore *.

* Conditional lock semaphore.  Identical to current
IpcSemaphoreTryLock(), except parameter is a PGSemaphore *.

Reserve/create/release would all be called in the postmaster process,
so they could communicate via malloc'd private memory (eg, an array
of semaphore IDs would be needed in the SysV case).  The remaining
operations would be invokable by any backend.

Comments?

I'd be willing to work on refactoring the existing SysV-based code
to meet this spec.
        regards, tom lane