Support using custom sockets with libuv or libnative

[mrmonday]

This is akin to supporting custom file descriptors, but for sockets. This allows for the implementation of raw sockets in an external library, as well as integration with other libraries that use sockets such as zeromq.

It exposes a lot more of liblibc than might be desirable, but the other alternative is to add a lot of additional code which probably shouldn't be in the standard library (it quickly explodes into something monstrous like pull #11410, and that was by no means complete). This should be a minimal subset which will allow other libraries to build upon.

[m-r-r]

This would also allow to write network daemons with socket activation support, for instance.
I hope this PR will be merged.

[alexcrichton]

The details of rtio are largely private, and I would rather not make this a public function as rtio should in general be hidden. How come this was made public?

[mrmonday]

So in order to use socket_from_raw_fd, you do the following (as std::io::* does for anything else in IoFactory):

LocalIo::maybe_raise(|io| {
    io.socket_from_raw_fd(...)
    ...
}).map_err(IoError::from_rtio_error)

To convert from rt::IoError to std::io::IoError. Since it will be used outside of std, there needs to be a way to convert the error. I'd happily make this private if you can think of a way to avoid this.

[alexcrichton]

In general our story for extending I/O isn't so great at the moment. As you've discovered it looks like there's going to be lots of duplication between librustuv and libnative if we go down this road, which is a little unfortunate. I think this falls into the same category of where this shouldn't really exist, but it's an unfortunate necessity.

[mrmonday]

I believe I've fixed all the things you brought up @alexcrichton, with the exception of code duplication/other things inherent to the way I/O is currently done - let me know if I missed anything.

[alexcrichton]

These three fields aren't necessary if the handle isn't cloneable.

[alexcrichton]

Ah I see it is now cloneable

[alexcrichton]

I'm not entirely thrilled about all the duplication between librustuv and libnative, this seems like a large indication that a better design is possible here. That being said this is all experimental and hidden from normal users so we can stomach this for now certainly.

Also, there are 0 tests for this new functionality, is there any way that we can add tests?

[mrmonday]

What kind of tests would you like? There aren't many (if any) tests for any of the related code in these crates. I can certainly add some for this.

[alexcrichton]

The vast majority of the tests are all in std::io, not in rustuv or native (which explains the apparent lack of tests). I wouldn't necessarily look for something in particular but rather just tests that at least exercise all the code paths here to make sure everything checks out. You could make a private std::io::raw_net module for testing this and use the iotest! macro if you'd like.

Some tests you may want to write:

• send/receive smoke tests
• clone() and concurrent send/receive
• clone() and concurrent drops

You'll want to be pretty careful with the tests because there's not a whole lot of error handling here so the tests are susceptible to EINTR or possibly EAGAIN spuriously

[mrmonday]

I have a full suite of tests for these in my own library - these require a lot of additional code (and root access) unfortunately so cannot really be included here. I'll try and make up some lower level tests without the dependencies/root requirement which could be included.