Re: darwin pgsql patches - Mailing list pgsql-patches

From Ian Lance Taylor
Subject Re: darwin pgsql patches
Date
Msg-id 20001205180050.8690.qmail@daffy.airs.com
Whole thread Raw
In response to Re: darwin pgsql patches  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: darwin pgsql patches
List pgsql-patches
   Date: Tue, 05 Dec 2000 12:28:59 -0500
   From: Tom Lane <tgl@sss.pgh.pa.us>

   Ian Lance Taylor <ian@airs.com> writes:
   > The POSIX semaphore interface comes from the pthreads work.  In my
   > opinion, the System V IPC calls are badly designed.

   Badly implemented, I'll grant you --- the resource limits in a typical
   configuration are ridiculously low.  I'm not sure the API as such is
   particularly good or bad.

A matter of taste, I suppose.

   > However, on systems which do fully implement POSIX semaphores, it
   > should be easy for Postgres to use them.  They should be created in
   > the shared memory segment.

   Huh?  Are POSIX semaphores objects in user memory space, instead of
   in the kernel?  I'm getting more and more confused.  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

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

Yes.  POSIX.1 standardizes mmap instead.

Ian

pgsql-patches by date:

Previous
From: Stephan Szabo
Date:
Subject: Fixes for checking unique constraints on RI creation
Next
From: Tom Lane
Date:
Subject: Re: darwin pgsql patches