Re: why roll-your-own s_lock? / improving scalability - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: why roll-your-own s_lock? / improving scalability
Date
Msg-id 20120626214442.GA13553@svana.org
Whole thread Raw
In response to Re: why roll-your-own s_lock? / improving scalability  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: why roll-your-own s_lock? / improving scalability
List pgsql-hackers
On Tue, Jun 26, 2012 at 01:46:06PM -0500, Merlin Moncure wrote:
> Well, that would introduce a backend dependency on pthreads, which is
> unpleasant.  Also you'd need to feature test via
> _POSIX_THREAD_PROCESS_SHARED to make sure you can mutex between
> processes (and configure your mutexes as such when you do).  There are
> probably other reasons why this can't be done, but I personally don' t
> klnow of any.

And then you have fabulous things like:

https://git.reviewboard.kde.org/r/102145/
(OSX defines _POSIX_THREAD_PROCESS_SHARED but does not actually support
it.)

Seems not very well tested in any case.

It might be worthwhile testing futexes on Linux though, they are
specifically supported on any kind of shared memory (shm/mmap/fork/etc)
and quite well tested.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.  -- Arthur Schopenhauer

pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Posix Shared Mem patch
Next
From: Daniel Farina
Date:
Subject: Re: pg_terminate_backend for same-role