[ruby-core:23841] Re: inheriting socket in child process on native Windows

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:[e-mail]] 
Sent: Saturday, June 13, 2009 5:36 AM
To: [e-mail]
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