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): 1. Provide guaranteed wsastartup/finalizer and sockopt open type conversion. 2. 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. 3. 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?
on 2006-02-23 09:55