From: | "Marc G(dot) Fournier" <scrappy(at)hub(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | mlw <markw(at)mohawksoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Native Windows, Apache Portable Runtime |
Date: | 2002-05-06 03:43:02 |
Message-ID: | 20020506004243.Y32524-100000@mail1.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Well, I guess that just saved *me* alot of work ... thanks ...
On Sat, 4 May 2002, Tom Lane wrote:
> mlw <markw(at)mohawksoft(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-06 03:50:54 | Re: Musings |
Previous Message | Marc G. Fournier | 2002-05-06 03:41:00 | Re: Native Windows, Apache Portable Runtime |