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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
