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. + ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
