"Bruce Momjian" <pgman@candle.pha.pa.us> wrote
> > In port/win32.h, we have
> >
> > #undef EAGAIN
> > #undef EINTR
> > #define EINTR WSAEINTR
> > #define EAGAIN WSAEWOULDBLOCK
> >
> > What's the rationale of doing so?
>
> We did this so that our code could refer to EINTR/EAGAIN without
> port-specific tests.
>
AFAICS, by doing so, the EINTR/EAGAIN will be translated into
WSAINTR/WSAEWOULDBLOCK through *all* the backend code. That's seems not
appropriate for the code not involving any socket stuff ... I think we need
a fix here.
> > (2) What's happened here?
> > It may come from PGSemaphoreReset(), and win32 semop() looks like this:
> >
> > ret = WaitForMultipleObjectsEx(2, wh, FALSE, (sops[0].sem_flg &
> > IPC_NOWAIT) ? 0 : INFINITE, TRUE);
> > ...
> > else if (ret == WAIT_OBJECT_0 + 1 || ret == WAIT_IO_COMPLETION)
> > {
> > pgwin32_dispatch_queued_signals();
> > errno = EINTR;
> > }
> > else if (ret == WAIT_TIMEOUT)
> > errno = EAGAIN;
> >
> > So it seems the EINTR is caused by an incoming signal, the EAGAIN is
caused
> > by a TIMEOUT ... any ideas?
>
> I looked at the documentation for the function:
>
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitformultipleobjectsex.asp
>
> and it isn't clear what return failure values it has. We certainly
> could loop on WSAEINTR. Can you test it?
>
Yeah, looking at other code of using semop(), we could plug in a loop in the
win32 semctl():
/* Quickly lock/unlock the semaphore (if we can) */
+ do
+ {
+ errStatus = semop(semId, &sops, 1);
+ } while (errStatus < 0 && errno == EINTR);
if (semop(semId, &sops, 1) < 0)
return -1;
But:
(1) The EINTR problem happens rather rare, so testing it is difficult;
(2) I would rather not doing the above changes before we understand what's
happened here, especially when we have seen a EAGAIN reported here.
Regards,
Qingqing
