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