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

> "Cyril VELTER" <cyril.velter@libertysurf.fr> writes:
> >     Also why not do the header fillup outside of PGSharedMemoryCreate ?
>
> Well, (a) I wasn't really concerned about defining an all-new API for
> shmem, and (b) I think the header is largely dependent on the semantics
> of SysV shmem anyway.  A different shmem implementation might need
> different fields in there.
   Are the PGShmemHeader fields only used by 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);
>
> How does that solve the problem of determining whether a *previously*
> created shmem block is still in use?  The point here is to be able to
> trace the connection from a data directory to active backends via their
> connections to a shared memory block --- take a look at
> RecordSharedMemoryInLockFile, which is the flip side of
> SharedMemoryIsInUse.
>
   Ok, I overlooked that, my proposal for PGSharedMemoryIsInUse doesn't
make sense (and it doesn't matter on Beos because shared mem segments are
automaticaly reaped at the end of the process).


> >     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);
>
> No strong feelings about this --- it looks like the same BeOS-specific
> hack under a different name ;-)
>
> >      This will allow the following calls for each fork to removed :
>
> >     beos_before_backend_startup
> >     beos_backend_startup_failed
> >     beos_backend_startup
>
> How so?  If those calls were needed before, why won't all three still
> be needed?

   In the current hack, I've to iterate over all sharedmem segments (system
wide) to find the original one by name. There is a race condition here if
several backend are starting at the same time. beos_before_backend_startup
beos_backend_startup_failed acquire / release a semaphore which prevent
several fork at the same time.

   With the proposed API, I would be able to store some specific info about
the shared mem segment (the beos handle of the original one created by
postmaster) which will be accessible to the backend after the fork. This
will remove the race condition and the need of the three calls. This will
also improve mutliple backend startup time cause now forks are serialized.
   This was just a though, current implementation works fine.

           cyril