Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Nov 15, 2010 at 11:12 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hmm ... I just remembered the reason why we didn't use a spinlock in
>> these functions already. �Namely, that it's unsafe for a signal handler
>> to try to acquire a spinlock that the interrupted code might be holding.
> The signal handler just checks a process-local, volatile variable
> called "waiting" (which should be fine) and then sends a self-pipe
> byte. It deliberately *doesn't* take a spinlock.
I'm not talking about latch_sigusr1_handler. I'm talking about the
several already-existing signal handlers that call SetLatch. Now maybe
it's possible to prove that none of those can fire in a process that's
mucking with the same latch in-line, but that sounds fragile as heck;
and anyway what of future usage? Given that precedent, somebody is
going to write something unsafe at some point, and it'll fail only often
enough to be seen in the field but not in our testing.
regards, tom lane