Re: What (not) to do in signal handlers

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: What (not) to do in signal handlers
Дата
Msg-id 21805.992553058@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: What (not) to do in signal handlers  (Doug McNaught <doug@wireboard.com>)
Ответы Re: What (not) to do in signal handlers  (ncm@zembu.com (Nathan Myers))
Список pgsql-hackers
Doug McNaught <doug@wireboard.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> Hm.  That's one way, but is it really any cleaner than our existing
>> technique?  Since you still need to assume you can do a system call
>> in a signal handler, it doesn't seem like a real gain in
>> bulletproofness to me.

> Doing write() in a signal handler is safe; doing fprintf() (and
> friends) is not.

If we were calling the signal handlers from random places, then I'd
agree.  But we're not: we use sigblock to ensure that signals are only
serviced at the place in the postmaster main loop where select() is
called.  So there's no actual risk of reentrant use of non-reentrant
library functions.

Please recall that in practice the postmaster is extremely reliable.
The single bug we have seen with the signal handlers in recent releases
was the problem that they were clobbering errno, which was easily fixed
by saving/restoring errno.  This same bug would have arisen (though at
such low probability we'd likely never have solved it) in a signal
handler that only invoked write().  So I find it difficult to buy the
argument that there's any net gain in robustness to be had here.

In short: this code isn't broken, and so I'm not convinced we should
"fix" it.
        regards, tom lane


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

Предыдущее
От: Doug McNaught
Дата:
Сообщение: Re: What (not) to do in signal handlers
Следующее
От: ncm@zembu.com (Nathan Myers)
Дата:
Сообщение: Re: What (not) to do in signal handlers