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

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