RFC: Replace ports with pipes

[eholk]

This is mostly just a tracking issue to hang other bugs off of. Assuming we can write all the programs we need to with pipes instead of ports and chans, we should replace the port/chan system with pipes.

[eholk]

Pipes are not an exact match, but with things like stream, port_set and shared_chan, we have reasonable replacements for most of the chan/port idioms. All that remains now is finding all the code and rewriting it.

The way pipes interact with native code will be tricky.

[graydon]

@eholk could you clarify what you mean by the last comment ("the way pipes interact with native code will be tricky")?

Otherwise I agree, it sounds like pipes are overall superior in most ways to the older ports and channels, I'm happy to switch to them.

[eholk]

@graydon Ports have a representation in the runtime, which means native code could call rust_port::send, or whatever the appropriate method is if they want to deliver a message to a Rust task. As far as I know, this was never done.

The tricky part that pipes would actually need to handle now is in core::priv, where we store a chan casted as a pointer in a global variable in the runtime. This is how we can have a single task to manage, for example, the OS environment, but any task can get access to it at any time.

With pipes, this is problematic for a couple reasons. First off, we can't just cast a pipe to a pointer, because they are not word sized anymore. Pipes can't directly be shared, although we could use pipes::shared_chan to emulate this. In my mind, the hardest issue is that someone needs to run the destructor on the pipe that somehow got stored in global memory. I guess this could just be the OS environment task (or the equivalent task for libuv).

[brson]

Done.