Re: why roll-your-own s_lock? / improving scalability

Поиск
Список
Период
Сортировка
От Martijn van Oosterhout
Тема Re: why roll-your-own s_lock? / improving scalability
Дата
Msg-id 20120626214442.GA13553@svana.org
обсуждение исходный текст
Ответ на Re: why roll-your-own s_lock? / improving scalability  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: why roll-your-own s_lock? / improving scalability  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Posix Shared Mem patch
Следующее
От: Daniel Farina
Дата:
Сообщение: Re: pg_terminate_backend for same-role