Fix Windows implementation of PGSemaphoreLock.

The original coding failed to reset ImmediateInterruptOK before returning,
which would potentially allow a subsequent query-cancel interrupt to be
accepted at an unsafe point.  This is a really nasty bug since it's so hard
to predict the consequences, but they could be unpleasant.

Also, ensure that signal handlers are serviced before this function
returns, even if the semaphore is already set.  This should make the
behavior more like Unix.

Back-patch to all supported versions.
This commit is contained in:
Tom Lane 2012-05-10 13:36:14 -04:00
parent 8ebc908c57
commit ada8fa08fc
1 changed files with 12 additions and 8 deletions

View File

@ -121,8 +121,13 @@ PGSemaphoreLock(PGSemaphore sema, bool interruptOK)
DWORD ret;
HANDLE wh[2];
wh[0] = *sema;
wh[1] = pgwin32_signal_event;
/*
* Note: pgwin32_signal_event should be first to ensure that it will be
* reported when multiple events are set. We want to guarantee that
* pending signals are serviced.
*/
wh[0] = pgwin32_signal_event;
wh[1] = *sema;
/*
* As in other implementations of PGSemaphoreLock, we need to check for
@ -135,20 +140,19 @@ PGSemaphoreLock(PGSemaphore sema, bool interruptOK)
ImmediateInterruptOK = interruptOK;
CHECK_FOR_INTERRUPTS();
errno = 0;
ret = WaitForMultipleObjectsEx(2, wh, FALSE, INFINITE, TRUE);
if (ret == WAIT_OBJECT_0)
{
/* We got it! */
return;
}
else if (ret == WAIT_OBJECT_0 + 1)
{
/* Signal event is set - we have a signal to deliver */
pgwin32_dispatch_queued_signals();
errno = EINTR;
}
else if (ret == WAIT_OBJECT_0 + 1)
{
/* We got it! */
errno = 0;
}
else
/* Otherwise we are in trouble */
errno = EIDRM;