Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Дата
Msg-id 10061.1283978969@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)  (Martijn van Oosterhout <kleptog@svana.org>)
Список pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> If the issue is just that select() doesn't get interrupted and we don't
> care about a couple of syscalls, would it not be better to simply use
> sigaction to turn on SA_RESTART just prior to the select() and turn it
> off just after. Or are these systems so broken that select() won't be
> interrupted, even if the signal handler is explicitly configured to do
> so?

I think you mean turn *off* SA_RESTART.  We'd have to do that for each
signal that we were concerned about allowing to interrupt the select(),
so it's more than just two added calls.  Another small problem is that
the latch code doesn't/shouldn't know what handlers are active, and
AFAICS you can't use sigaction() to flip that flag without setting the
handler address too.  So while maybe we could do it that way, it'd be
pretty dang messy.

In my mind the main value of the Latch code will be to have a clean
platform-independent API for waiting.  Why all the angst about whether
the implementation underneath is clean or not?  It's more important that
it *works* and we don't have to worry about whether it will break on
platform XYZ.
        regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: testing plpython3u on 9.0beta3
Следующее
От: Tom Lane
Дата:
Сообщение: Postgres 9.0.0 release scheduled