I don't think I gave enough context... I wrote a sample C++ app that just uses HANDLEs/SOCKETs everywhere, and everything works as I would expect. Then I wrote the Ruby equivalent and found the place in rb_w32_select where Ruby was stopping my scenario from working and used some very slight runtime tweaking in the debugger to remove the check. Then everything worked as expected, which shows at least in that scenario that the sockets themselves were functioning properly in the child process. In the IO.new case, there's another problem I came across when writing the C++ app that I forgot to mention. If you have a SOCKET that you got from, say, accept(), you can't use read() and write() on it (well, on an fd that maps to it). They both failed with ERROR_BAD_COMMAND in my C++ app. I had to use send() and recv() for it to work properly. Looks like the IO class doesn't have send and recv, so if I wanted to use it to wrap a socket on Windows, I'd have to cast it to a TCPSocket object to get the right methods. Still, I'm not sure that is the reason for the "file is not open for writing" error. I suspect Ruby is getting this error because it's using a check that is appropriate for testing whether a file is open for writing on Windows, but not for testing if a SOCKET is accepting writes. I don't see anything obvious in rb_io_initialize, but I bet I'm not looking in the right place. Thanks -Kedar -----Original Message----- From: Roger Pack [mailto:rogerdpack / gmail.com] Sent: Saturday, June 13, 2009 5:36 AM To: ruby-core / ruby-lang.org Subject: [ruby-core:23838] Re: inheriting socket in child process on native Windows > I tried that with both the HANDLE value and with an fd value that I > associate with the HANDLE value using _open_osfhandle. The latter fails with > EBADF, and the former fails with "the file is not open for writing." I fully > expected the former, and the latter sounds a bit like the same class of > problem, where I'm basically bringing in a foreign file descriptor that Ruby > doesn't really "know about." Having never done it, it's possible that your "file is not open for writing" means the fd wasn't transferred across apps successfully. One thing that might help might be to try and get something working using straight C first, then attempt its ruby equiv. Cheers! -=r