Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:

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


pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group