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

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.

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

			regards, tom lane