Re: FATAL: semctl(1672698088, 12, SETVAL, 0) failed

Qingqing Zhou wrote:
>
> "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.

Uh, how do we handle it now?  I thought we did just that.

> 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.

OK, so how do we find the answer?

--
  Bruce Momjian   http://candle.pha.pa.us
  SRA OSS, Inc.   http://www.sraoss.com

  + If your life is a hard drive, Christ can be your backup. +