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

Like I told Marc, I don't care. You spec out what you want and I'll write it
for Windows. 

That being said, a SysV IPC interface for native Windows would be kind of cool
to have.


Tom Lane wrote:
> 
> 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