Обсуждение: WaitLatchOrSocket API needs more thought for socket error conditions

After further consideration, I think the patch I committed here:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=31ad6553646c81f3ce8fccf8aef1a1134a7864c7
may have been an overly hasty band-aid rather than a good fix.
The question that needs to be faced is: what should WaitLatchOrSocket
do with an EOF or error condition on the provided socket?  The
above-linked patch translates such conditions into a WL_SOCKET_READABLE
return bit, which is perhaps fine as long as the caller asked for that,
but what if only WL_SOCKET_WRITABLE was asked for?  The current Unix code
would go into an infinite loop (at least in the poll() case), and I'm
not too sure what the Windows code would do.

One possible answer is to just legislate that callers mustn't specify
WL_SOCKET_WRITABLE without WL_SOCKET_READABLE (either just as
documentation, or probably better with an Assert check).  The existing
callers would all be fine with this, and I'm not sure whether there will
ever be a case where we'd like to wait on a write-only socket.

Or we could allow EOF/error cases to set both WL_SOCKET_READABLE and
WL_SOCKET_WRITABLE according to what the caller passed.  This seems
a bit ugly to me though.  In particular, you definitely can't write
on a closed socket.

Or we could add a third return bit WL_SOCKET_ERROR, but I'm not sure
that the callers really care enough to deal with the extra complexity;
there seems plenty of scope for errors of omission at the call sites
if we do it that way.

Thoughts?
        regards, tom lane

On 13 May 2012 02:48, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> One possible answer is to just legislate that callers mustn't specify
> WL_SOCKET_WRITABLE without WL_SOCKET_READABLE (either just as
> documentation, or probably better with an Assert check).  The existing
> callers would all be fine with this, and I'm not sure whether there will
> ever be a case where we'd like to wait on a write-only socket.

+1 . Let the improbable requirement of being able to wait on a
write-only socket actually emerge before we engineer a solution.

I think that we might have avoided accepting the poll()-based
implementation in the first place if these subtleties were considered
earlier, since IIRC the justification for introducing it was rather
weak.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Peter Geoghegan <peter@2ndquadrant.com> writes:
> I think that we might have avoided accepting the poll()-based
> implementation in the first place if these subtleties were considered
> earlier, since IIRC the justification for introducing it was rather
> weak.

I'm not exactly sure that the select-based implementation isn't buggy
too.  It just ignores the possibility of error conditions on the
socket(s).  In any case, we are using poll interchangeably with select
in most places.
        regards, tom lane