From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Cyril VELTER" <cyril(dot)velter(at)libertysurf(dot)fr> |
Cc: | "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Native Windows, Apache Portable Runtime |
Date: | 2002-05-05 23:21:31 |
Message-ID: | 18616.1020640891@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Cyril VELTER" <cyril(dot)velter(at)libertysurf(dot)fr> writes:
> 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 ?
You can define 'em however you want. For SysV shmem they are the shmem
key and id.
> 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.
> 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.
> 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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-05 23:41:00 | Re: Number of attributes in HeapTupleHeader |
Previous Message | Hiroshi Inoue | 2002-05-05 23:15:09 | Re: Using views and MS access via odbc |