Re: What (not) to do in signal handlers
От | Tom Lane |
---|---|
Тема | Re: What (not) to do in signal handlers |
Дата | |
Msg-id | 21586.992550434@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: What (not) to do in signal handlers (ncm@zembu.com (Nathan Myers)) |
Ответы |
Re: What (not) to do in signal handlers
|
Список | pgsql-hackers |
ncm@zembu.com (Nathan Myers) writes: > It could open a pipe, and write(2) a byte to it in the signal handler, > and then have select(2) watch that pipe. (SIGHUP could use the same pipe.) > Of course this is still a system call in a signal handler, but it can't > (modulo coding bugs) fail. 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. > A pipe per backend might be considered pretty expensive. Pipe per postmaster, no? That doesn't seem like a huge cost. I'd be more concerned about the two extra kernel calls (write and read) per signal received, actually. regards, tom lane
В списке pgsql-hackers по дате отправления: