Re: Native Windows, Apache Portable Runtime - Mailing list pgsql-hackers

Hi Tom,
   I'll do the necessary change for the BeOS port. On a first look, this
will greatly simplify the semaphore layer as the new API map quite well with
the BeOS one.
   I find the semaphore API quite clean but have some question on the
Shared memory one. The Id's passed to PGSharedMemoryIsInUse aren't clear to
me. How id1 and id1 are related to the port parameter of
PGSharedMemoryCreate ?   Also why not do the header fillup outside of PGSharedMemoryCreate ?

   What about using an API similar to the sema one :       PGShmemHeader * PGSharedMemoryCreate(PGShmem shmem,uint32
size,bool
 
makePrivate, int memKey);       bool PGSharedMemoryIsInUse(PGShmem shmem);
       where PGShmem is an implementation definded struct (including header
datas).

   On a side note, after these API change, Beos will still need an Hack for
shared memory, because all shared memory segments are in copy on write mode
in the forked process. One solution could be to have an explicit attach call
in the forked process :       PGSharedMemoryAttach(PGShmem shmem);
   This could be a no op for SYSV shmem.
    This will allow the following calls for each fork to removed :
   beos_before_backend_startup   beos_backend_startup_failed   beos_backend_startup
                   cyril


----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "mlw" <markw@mohawksoft.com>
Cc: "PostgreSQL-development" <pgsql-hackers@postgresql.org>
Sent: Saturday, May 04, 2002 6:56 PM
Subject: Re: [HACKERS] Native Windows, Apache Portable Runtime


> 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
> like
> USE_DARWIN_SEMAPHORES=1
> SEMA_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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org