I’ve undef’d the macros (bind, setsockopt, etc) in my C file but I’m
wondering if I’m safe in doing so. I see the redirect functions do a
few things that are probably important for the ruby core on win32
(please correct me if I misunderstand these principles):
- Provide guaranteed wsastartup/finalizer and sockopt open type
conversion. - Make all sockets references redirect through a file handle (which
is cast away on all wrapped socket calls). This seems to have
something to do with select() and it’s usage in ruby threading. - Wrap all calls in critical section or spin lock (based on OS) since
multi-threaded CRT is not used in link.
The extension I’m writing takes advantage of the async socket
capabilities but handles the sockets directly (for overlapped
completion ports). The hidden redirection from say bind() to
rb_w32_bind() and subsequent call to _get_osfhandle() puts up a
0x80072736 (WSAENOTSOCK) in my code so I had to track down this hidden
indirection.
I can’t seem to interoperate with the file handle redirection and I
don’t need the winsock startup glue so now I’m just trying to
understand how the API locking is going to affect my code. The only
time in a ruby app multiple native threads seem to be running is in
the call to flock or in an extension.
So are these wrapper macros there for extension writers? Am I safe in
ignoring them if I provide my own locking mechanisms?