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

> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, May 03, 2002 3:07 PM
> To: mlw
> Cc: Marc G. Fournier; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] HEADS UP: Win32/OS2/BeOS native ports
>
>
> 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.

It's already been done.  Here is a freely available C++ implementation
(licensing similar to PostgreSQL):
http://www.cs.wustl.edu/~schmidt/ACE.html