Cloning Streams is Untenable

[illegalprime]

Currently I am trying to refactor the idea of a Stream in this library.
A stream should simply be something that can be written to and read from.

The hyper has had some issues with this idea as well, and recently refactored their NetworkStream which implemented (in my opinion too many) traits: Read + Write + Any + Send + Typeable, into a Transport trait which simply implements Read + Write (and Evented for mio support).

The Problem

We are supporting a (maybe strange, maybe normal) use case of being able to split the client into two owned copies (sender and receiver) so they may be used in different threads.

This creates a need for streams to support the ability to clone themselves into two owned copies.
This is OK with TcpStream, but in SslStream the try_clone(&self) function is deprecated in newer versions and will be removed.

Hyper integration is also blocked since Hyper's NetworkStream and now Transport do not implement try_clone(&self), presumably because of the above reason.

Solution: Remove Support, Switch to Arc<Mutex<Client<...>>>

The solution as I see it is to no longer support multi-threading as a first class use-case.
If someone needs to use a client on multiple threads they can wrap it in a lock.
I am under the impression that this is how it currently works when one clones a TcpStream and tries to read and write to it: the kernel has a lock on this file descriptor and blocks calls accordingly. Please correct me if I am wrong. This change would just make the locking more explicit.

This would also allow the Client to not own its stream (which is wanted in the use case of hyper integration).

Multi-threading for servers is still practical though, since each Client the server creates can be dispatched to worker threads safely.

For Those Still Holding Out

There will be a method on the Client called .stream(&self) -> &S which would return the concrete type of the stream the Client is using, so it can be cloned by people who want to.

Implications

1. Client can no longer be split.
2. Sender and Receiver will no longer be able to own/borrow their stream.

[cyderize]

Thanks @illegalprime, this is a good point.

Hmm, I'm not sure that the kernel blocks the same way that it would with a Arc<Mutex<...>>. If we made users use Arc<Mutex<Client<...>>>, then you wouldn't be able to read and write concurrently (since you would always need to acquire the same mutex to do either). But when you clone a stream, you can simultaneously read and write since (as far as I know) they have different locks for reading and writing.

I guess if you are using Arc<Mutex<Client<...>>> then it would be clear that there is only one lock for both reading and writing, though, so users couldn't really be 'confused' by this.

But if for example we consider the case of having basically a send loop and receive loop as in the examples/client.rs (but with added Arc<Mutex<...>>), then the receive loop will stop the send loop from being able to do anything until the receive loop receives a full message and releases the mutex.

Even if we used non blocking sockets in that case we would still be unable to send while a message was being received (and vice versa), although we'd be able to send if there was was no message being received as that would release the receive loop's mutex and allow the send loop to acquire it.

That's one implication I can think of, but all in all, it's probably not really that much of a problem - it's likely not that important to be sending/receiving messages simultaneously. If you're slowing receiving a message from someone such that you'd notice not being able to send to them yet, you probably don't need to send them your message right at this instant anyway - you can probably wait until they're done and it'll be fine.

I do like being able to read and write simultaneously, but I don't really have an issue with this solution. If anyone has a case where they absolutely need to be able to do that then they can probably find a way with .stream().

[illegalprime]

I'm going to talk to the guys at Hyper, maybe we can get them to include a try_clone in their implementation of a network transport.
I will do more research on this, a different solution would be to keep support but find a way to clone an SslStream and get hyper to change their ways and include some method of cloning streams.

[illegalprime]

Solved with #80, closing.