UNIXServer.for_fd doesn't work

The test/spec should probably go into RubySpec, and I suppose just creating a server and a client and then creating another server object with for_fd would work fine; there's no real need to pass it across processes to show that for_fd is working, right?

Patch looks fine; I can apply it when we have some specs to include. Thank you!

Well I don't think it's that simple. There are two kinds of file descriptors in JRuby, internals ones which do not correspond to actual OS file descriptors, and external ones which do correspond to OS file descriptors. Pretty much everything except FFI::IO use internal file descriptors. For example:

$ jirb 3</some/file
irb(main):001:0> f = File.for_fd(3)
Errno::EBADF: Bad file descriptor - Bad file descriptor
        from (irb):2:in `initialize'
        from (irb):2:in `for_fd'
        from (irb):2
irb(main):002:0> require 'ffi'     
=> true
irb(main):003:0> f = FFI::IO.for_fd(3)
irb(main):006:0> f.fileno
=> 6

UNIXServer#fileno returns an internal file descriptor, which UNIXServer.for_fd doesn't accept. This also makes me wonder whether accepting OS file descriptors in for_fd is a good idea.

Hongli: Yes, that certainly complicates things. Part of the problem is that Java doesn't give us access to the raw fd values, but another part is that JRuby can wrap an IO around streams that don't have an IO associated with them.

In some cases we can dig out the real FD, but it involves JVM-specific code that secured environments might not permit. In this case, however, UNIXServer/Socket are both implemented with native calls, so we can get the real FD out of them. We could also implement for_fd to fall back on a native call when it's not possible to find a real one.

There are potentially some additional improvements in Java 7 that may help these cases a bit more. For now we do what we can.

I had some thoughts on automagically making IO.for_fd() work with native fds by first checking if the fd is valid by calling fcntl(fd, F_GETFL). If it returns -1, then the fd is not valid, otherwise wrap it in a nio stream, such as FFI::IO.for_fd does, or the unixserver stuff does.

That still won't solve the problem of f.fileno not reflecting the underlying fileno. Not sure if there will be complications from two different File objects reporting the same fileno (e.g. if they are used as a key in a hash, or otherwise relied upon).

Autodetecting whether it's a native fd is possible, but if there's an internal fd with the same number then it would be no longer possible to use for_fd with that internal fd.

Maybe it would be a good idea to ensure that internal fds are always < -1 so that they're always distinguishable from external fds.

Wayne: It definitely sounds doable. Then on systems where we don't have access to fcntl, we'd just always use bogus FDs like we do now, and real native FDs would work great. It may be that we can also dig out the fd on systems that allows us to reflectively access the internals of FileChannel or SocketChannel.

Hongli: Yes, I think we'd want to set aside a reasonable range for our bogus FDs, like perhaps in the >32bit signed int range. I think it's unlikely any system will assign FD numbers into the billions.