mswsock:Implement 3 functions by calling through SIO_GET_EXTENSION_FUNCTION_POINTER (try 2)
andrey.turkin at gmail.com
Sun Jul 6 11:25:24 CDT 2008
You're right, bulletproof mapping cannot be feasibly implemented here;
however, I can imagine only two use cases - either just AcceptEx calls,
or bunch of AcceptEx calls followed by GetAcceptExSockaddrs call and
AcceptEx call for each accepted connection. So, e.g. ring buffer of
reasonable length or some sort of hash should be enough. Anyway, for now
your currently implemented approach would be enough.
However, I've got some comments on this:
1) Cannot remember if global variables should be initialized to NULL or
not per Wine conventions, if yes then acceptex_fn and
acceptexsockaddrs_fn definitions should be changed accordingly. Also,
LPFN_ACCEPTEX, LPFN_GETACCEPTEXSOCKADDRS and LPFN_TRANSMITFILE typedefs
may be used instead of in-place definitions.
2) IMHO acceptex_guid and acceptexsockaddrs_guid should be locals to
AcceptEx and GetAcceptExSockaddrs, not globals (they wouldn't be used
elsewhere, right?). This changed from first version, maybe this was made
for a reason?
Jon Griffiths wrote:
> Based on Andreys comments, This version gathers the implementation ptrs when AcceptEx is called, using the accepting socket and avoiding calling WSIoctl with a 0 socket. I've added a comment regarding the circumstances under which we may need to modify this approach.
> We can't sensibly do any mapping between output buffers and sockets in mswsock - since we'd never know when to free a given mapping, we'd end up leaking them. When AcceptEx is implemented in ws2_32 it will need to own the mapping; it can then free it when the socket is closed.
More information about the wine-patches