Re: APC/socket fix (final?)

Hi all,

Magnus Hagander wrote:
> The third option is to redefine all these functions into our own, and
> implement our own emulation layer. This means our own select(), send(),
> recv() (more? I don't think so). And have these call the native winsock
> APIs (WSAEventSelect(), WSASend(), WSARecv() etc). These functions are
> designed to work in an APC environment.

I personally think this is the last possible option; I'd much rather stay as
close to *nix as possible. As you said, and I agree whole-heartedly that
there is a lot more code that can go wrong, and it seems unnecessary if we
have a suitable workaround, which I think we might.

> If you think my suggestion above is not a good one then yes, we can do
> this one. But I don't feel all that good about it (and specifically, I
> have not had it confirmed about recv() and send() yet - have asked, but
> not received a response yet).

Reading back through our discussions, I'm not at all concerned about recv()
+ send(), as they are well behaved. When interrupted, they SetLastError()
reasonably, and return < 0.

select(), however, is a different story. On APC interrupt, it returns a
seemingly valid value, doesn't set any of
errno/WSAGetLastError/GetLastError, and leaves the FD_SETs set, which we
concluded was impossible to work-around. However, it just occured to me that
we could wrap select() by augmenting the read_mask with an addition socket,
that we know will never be touched, and checking this socket on a "valid"
return. If this socket is still set, we know we got bitten by the APC/socket
interaction bug, and can set errno accordingly.

I've attached a proposal for /port. Comments?

Cheers,
Claudio

---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>