Re: darwin pgsql patches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ian Lance Taylor <ian(at)airs(dot)com>
Cc: bierman(at)apple(dot)com, pgsql-patches(at)postgresql(dot)org
Subject: Re: darwin pgsql patches
Date: 2000-12-05 19:46:20
Message-ID: 21508.976045580@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Ian Lance Taylor <ian(at)airs(dot)com> writes:
> Where can I find
> a description of the POSIX version of semaphores?

> POSIX semaphores can in principle live in either user space or kernel
> space. They are mainly designed for user space, though.

> If you have access to a GNU/Linux system, you can do `man sem_init'.
> Or, I just did a quick web search, and found this:
> http://helix.nih.gov/cgi-bin/man.cgi?section=3&topic=sem_init

Hm. It's clearly possible to base Postgres's semaphore stuff on unnamed
Posix semaphores living in the shared memory area (which eliminates the
issue of inheritance by child processes). You'd need to revise the API
presented by ipc.c so that it doesn't depend on semaphore IDs and keys.
I'm inclined to envision a type "pg_semaphore" that's either "sem_t" in
the POSIX case or
struct { int sem_id, sem_num; }
in the SysV case, and then all the ipc.c routines take a pg_semaphore *.
There's some code to allocate semaphores to backends in proc.c that
would need to be rewritten, but the impact ought to be pretty localized.

How efficient are POSIX semaphores, anyway? I wonder if we couldn't
also replace spinlocks with them...

> BTW, should I expect that POSIX also ignored the SysV IPC spec for
> shared memory?

> Yes. POSIX.1 standardizes mmap instead.

Another TODO item I suppose :-(

regards, tom lane

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2000-12-05 19:59:16 Re: Fixes for checking unique constraints on RI creation
Previous Message Ian Lance Taylor 2000-12-05 18:00:50 Re: darwin pgsql patches