Re: Latches with weak memory ordering (Re: max_wal_senders must die)

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Latches with weak memory ordering (Re: max_wal_senders must die)
Дата
Msg-id 201011191549.57372.andres@anarazel.de
обсуждение исходный текст
Ответ на Re: Latches with weak memory ordering (Re: max_wal_senders must die)  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Latches with weak memory ordering (Re: max_wal_senders must die)  (Aidan Van Dyk <aidan@highrise.ca>)
Список pgsql-hackers
On Friday 19 November 2010 15:38:37 Robert Haas wrote:
> Eh, really?  If there's a workaround for platforms for which we don't
> know what the appropriate read-fencing incantation is, then I'd feel
> more comfortable about doing this.  But I don't see how to make that
> work.  The whole problem here is that API is designed in such a way
> that the signal handler might be invoked when the lock that it needs
> to grab is already held by the same process.  The reason memory
> barriers solve the problem is because they'll be atomically released
> when we jump into the signal handler, but that is not true of a
> spin-lock or a semaphore.
Well, its not generally true - you are right there. But there is a wide range 
for syscalls available where its inherently true (which is what I sloppily 
referred to). And you are allowed to call a, although quite restricted, set of 
system calls even in signal handlers. I don't have the list for older posix 
versions in mind, but for 2003 you can choose something from several like 
write, lseek,setpgid which inherently have to serialize. And I am quite sure 
there were sensible calls for earlier versions.

Andres


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Latches with weak memory ordering (Re: max_wal_senders must die)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Latches with weak memory ordering (Re: max_wal_senders must die)