Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!

On 19/08/10 20:59, Tom Lane wrote:
> Offhand I'd suggest something like
>
> SetSleepInterrupt() -- called by signal handlers, writes pipe
> ClearSleepInterrupt() -- called by sleep-and-do-something loops, clears pipe
>
> pg_usleep() itself remains the same, but it is now guaranteed to return
> immediately if SetSleepInterrupt is called, or has been called since the
> last ClearSleepInterrupt.

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.

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(). 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.

Actually ProcSendSignal()/ProcWaitForSignal() won't work as is, because
walsender doesn't have a PGPROC entry, but you could easily build a
similar mechanism, using PGSemaphoreLock/Unlock like
ProcSendSignal()/WaitForSignal() does.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com