replace channel-based timers with a recv_timeout method

[thestinger]

If it's done directly on channel types, it will be easier to use because it won't require the caller to worry about a pattern like select.

For the 1:1 case, this would just be a call to pthread_cond_timedwait after initializing the condition variable with CLOCK_MONOTONIC as the clock.

Windows condition variables expose a similar method taking a relative time, but there's no way to wait again for the remaining time after a spurious wake-up. If this is important, we can build the functionality on top of the win32 API or use another implementation.

For M:N threading it can either keep doing what it does now behind the scenes, or use an efficient timer/condvar contraption too.

[alexcrichton]

This is not the only reason that channel-based timers exist, and I don't think that they should be removed as part of this issue. I believe this issue should be about adding a recv_timeout method to channels.

Some uses for channel-based timers:

• reliable periodic timers (at least more so than continuously calling sleep())
• selection over a timer channel and a large number of other channels
• convenience with integration with the rest of our message passing runtime

[thestinger]

reliable periodic timers (at least more so than continuously calling sleep())

That's why the native sleeping API is divided into sleep_until(abstime) and sleep_for(reltime). POSIX condition variables are also based on an absolute time and a relative wait needs to be implemented based on that.

let mut abstime = monotonic();
loop {
    abstime.add_second(1);
    abstime.sleep_until();
    println("foo")
}

selection over a timer channel and a large number of other channels

It would be more efficient to have a timeout parameter to select like the native versions. Anyway, select isn't necessarily a good abstraction for Rust's channels. Go uses it to inject non-determinism to make scheduling less unfair, but Rust has native threads available.

convenience with integration with the rest of our message passing runtime

Having all of these inter-dependencies makes the standard library less useful to someone who needs more than it offers. If you need multiple-producer/multiple-consumer channels, bounded channels or just different performance characteristics (contiguous memory) then you're sold out of luck.

[pnkfelix]

Accepted for 1.0, P-backcompat-libs.

[brson]

I do feel a little uncomfortable about the timer API being coupled to channels, but I'm thinking we can let stability attributes deal with this, and if the 1.0 timer API isn't the best it's not the end of the world.

The biggest concern with leaving them together is that it makes refactoring channels and I/O into different crates difficult or impossible.

Nominating for removal from milestone.

[pnkfelix]

Leaving at P-backcompat-libs, but removing from 1.0 milestone

[alexcrichton]

Channel based timers are part of old_io and are not coming back as part of the new I/O. I've opened an RFC issue for adding recv_timeout which is useful no matter what. In light of channel-based timers not coming back, though, I'm going to close this in favor of the RFC issue as it will be a backwards compatible addition.