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
