Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

On 24/08/10 02:44, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com>  writes:
>> [ "latch" proposal ]
>
> This seems reasonably clean as far as signal conditions generated
> internally to Postgres go, but I remain unclear on how it helps for
> response to actual signals.

You can can set the latch in the signal handler.

Here's a first attempt at implementing that. To demonstrate how it 
works, I modified walsender to use the new latch facility, also to 
respond quickly to SIGHUP and SIGTERM.

There's two kinds of latches, local and global. Local latches can only 
be set from the same process - allowing you to replace pg_usleep() with 
something that is always interruptible by signals (by setting the latch 
in the signal handler). The global latches work the same, and indeed the 
implementation is the same, but the latch resides in shared memory, and 
can be set by any process attached to shared memory. On Unix, when you 
set a latch waited for by another process, the setter sends SIGUSR1 to 
the waiting process, and the signal handler sends the byte to the 
self-pipe to wake up the select().

On Windows, we use WaitEvent to wait on a latch, and SetEvent to wake 
up. The difference between global and local latches is that for global 
latches, the Event object needs to be created upfront at postmaster 
startup so that its inherited to all child processes, and stored in 
shared memory. A local Event object can be created only in the process 
that needs it.

I put the code in src/backend/storage/ipc/latch.c now, but it probably 
ought to go in src/backend/portability instead, with a separate 
win32_latch.c file for Windows.

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