Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!
От | Heikki Linnakangas |
---|---|
Тема | Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers! |
Дата | |
Msg-id | 4C6E8E13.4050307@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers! (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
|
Список | pgsql-hackers |
On 20/08/10 16:24, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes: >> Hmm, we have pg_usleep() calls in some fairly low-level functions, like >> mdunlink() and s_lock(). If someone has called SetSleepInterrupt(), we >> don't want those pg_usleep()s to return immediately. And pg_usleep() is >> used in some client code too. I think we need a separate sleep function >> for this. > > Well, we'd need some careful thought about which sleeps need what, but I > don't necessarily have an objection to a separate interruptable sleep > function. If we have to, we could also support multiple interrupts with multiple self-pipes, so that you can choose at pg_usleep() which ones to wake up on. >> Another idea is to not use unix signals at all, but ProcSendSignal() and >> ProcWaitForSignal(). We would not need the signal handler at all. >> Walsender would use ProcWaitForSignal() instead of pg_usleep() and >> backends that want to wake it up would use ProcSendSignal(). > > You keep on proposing solutions that only work for walsender :-(. Well yes, the other places where we use pg_usleep() are not really a problem as is. If as a side-effect we can make them respond more quickly to signals, with small changes, that's good, but walsender is the only one that's performance critical. That said, a select() based solution is my current favorite. > Most of the other places where we have pg_usleep actually do want > a timed sleep, I believe. It's also unclear that we can always expect > ProcSendSignal to be usable --- for example, stuff like SIGHUP would > be sent by processes that might not be connected to shared memory. > >> The problem >> is that there is currently no way to specify a timeout, but I presume >> the underlying semaphore operations have that capability, and we could >> expose it. > > They don't, or at least the semop-based implementation doesn't. There's semtimedop(). I don't know how portable it is, but it seems to exist at least on Linux, Solaris, HPUX and AIX. On what platforms do we use sysv semaphores? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: