2013-10-22 17:13:18 -05:00
|
|
|
// Copyright 2013 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2014-02-10 21:59:35 -06:00
|
|
|
use std::mem;
|
2013-11-01 11:36:21 -05:00
|
|
|
use std::rt::rtio::RtioTimer;
|
2014-02-10 21:59:35 -06:00
|
|
|
use std::rt::task::BlockedTask;
|
2013-10-22 17:13:18 -05:00
|
|
|
|
2013-12-12 19:47:48 -06:00
|
|
|
use homing::{HomeHandle, HomingIO};
|
2014-04-21 22:30:07 -05:00
|
|
|
use super::{UvHandle, ForbidUnwind, ForbidSwitch, wait_until_woken_after, Loop};
|
2013-12-12 19:47:48 -06:00
|
|
|
use uvio::UvIoFactory;
|
2013-10-22 17:13:18 -05:00
|
|
|
use uvll;
|
|
|
|
|
2013-11-01 11:36:21 -05:00
|
|
|
pub struct TimerWatcher {
|
2014-04-27 17:45:16 -05:00
|
|
|
pub handle: *uvll::uv_timer_t,
|
2013-12-12 19:47:48 -06:00
|
|
|
home: HomeHandle,
|
2013-11-01 11:36:21 -05:00
|
|
|
action: Option<NextAction>,
|
2014-02-10 21:59:35 -06:00
|
|
|
blocker: Option<BlockedTask>,
|
2013-12-15 20:17:43 -06:00
|
|
|
id: uint, // see comments in timer_cb
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
pub enum NextAction {
|
2014-02-10 21:59:35 -06:00
|
|
|
WakeTask,
|
2014-03-09 16:58:32 -05:00
|
|
|
SendOnce(Sender<()>),
|
|
|
|
SendMany(Sender<()>, uint),
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
2013-10-22 17:13:18 -05:00
|
|
|
|
|
|
|
impl TimerWatcher {
|
2014-05-05 20:56:44 -05:00
|
|
|
pub fn new(io: &mut UvIoFactory) -> Box<TimerWatcher> {
|
2014-04-21 22:30:07 -05:00
|
|
|
let handle = io.make_handle();
|
2014-04-25 03:08:02 -05:00
|
|
|
let me = box TimerWatcher::new_home(&io.loop_, handle);
|
2014-04-21 22:30:07 -05:00
|
|
|
me.install()
|
|
|
|
}
|
|
|
|
|
|
|
|
pub fn new_home(loop_: &Loop, home: HomeHandle) -> TimerWatcher {
|
2013-11-01 11:36:21 -05:00
|
|
|
let handle = UvHandle::alloc(None::<TimerWatcher>, uvll::UV_TIMER);
|
2014-04-21 22:30:07 -05:00
|
|
|
assert_eq!(unsafe { uvll::uv_timer_init(loop_.handle, handle) }, 0);
|
|
|
|
TimerWatcher {
|
2013-11-01 11:36:21 -05:00
|
|
|
handle: handle,
|
|
|
|
action: None,
|
2014-02-10 21:59:35 -06:00
|
|
|
blocker: None,
|
2014-04-21 22:30:07 -05:00
|
|
|
home: home,
|
2013-12-15 20:17:43 -06:00
|
|
|
id: 0,
|
2014-04-21 22:30:07 -05:00
|
|
|
}
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|
|
|
|
|
2014-04-18 15:23:56 -05:00
|
|
|
pub fn start(&mut self, f: uvll::uv_timer_cb, msecs: u64, period: u64) {
|
2013-11-01 11:36:21 -05:00
|
|
|
assert_eq!(unsafe {
|
2014-04-18 15:23:56 -05:00
|
|
|
uvll::uv_timer_start(self.handle, f, msecs, period)
|
2013-11-01 11:36:21 -05:00
|
|
|
}, 0)
|
|
|
|
}
|
|
|
|
|
2014-04-18 15:23:56 -05:00
|
|
|
pub fn stop(&mut self) {
|
2013-11-04 16:03:32 -06:00
|
|
|
assert_eq!(unsafe { uvll::uv_timer_stop(self.handle) }, 0)
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
2014-04-18 15:23:56 -05:00
|
|
|
|
|
|
|
pub unsafe fn set_data<T>(&mut self, data: *T) {
|
|
|
|
uvll::set_data_for_uv_handle(self.handle, data);
|
|
|
|
}
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
impl HomingIO for TimerWatcher {
|
2013-12-12 19:47:48 -06:00
|
|
|
fn home<'r>(&'r mut self) -> &'r mut HomeHandle { &mut self.home }
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
impl UvHandle<uvll::uv_timer_t> for TimerWatcher {
|
|
|
|
fn uv_handle(&self) -> *uvll::uv_timer_t { self.handle }
|
|
|
|
}
|
2013-10-22 17:13:18 -05:00
|
|
|
|
2013-11-01 11:36:21 -05:00
|
|
|
impl RtioTimer for TimerWatcher {
|
|
|
|
fn sleep(&mut self, msecs: u64) {
|
2013-11-09 13:02:16 -06:00
|
|
|
// As with all of the below functions, we must be extra careful when
|
|
|
|
// destroying the previous action. If the previous action was a channel,
|
|
|
|
// destroying it could invoke a context switch. For these situtations,
|
|
|
|
// we must temporarily un-home ourselves, then destroy the action, and
|
|
|
|
// then re-home again.
|
|
|
|
let missile = self.fire_homing_missile();
|
2013-12-15 20:17:43 -06:00
|
|
|
self.id += 1;
|
2013-11-09 13:02:16 -06:00
|
|
|
self.stop();
|
2014-02-10 21:59:35 -06:00
|
|
|
let _missile = match mem::replace(&mut self.action, None) {
|
2013-11-09 13:02:16 -06:00
|
|
|
None => missile, // no need to do a homing dance
|
|
|
|
Some(action) => {
|
2013-12-03 00:37:26 -06:00
|
|
|
drop(missile); // un-home ourself
|
|
|
|
drop(action); // destroy the previous action
|
2013-11-09 13:02:16 -06:00
|
|
|
self.fire_homing_missile() // re-home ourself
|
|
|
|
}
|
|
|
|
};
|
2013-11-07 17:13:06 -06:00
|
|
|
|
|
|
|
// If the descheduling operation unwinds after the timer has been
|
|
|
|
// started, then we need to call stop on the timer.
|
|
|
|
let _f = ForbidUnwind::new("timer");
|
|
|
|
|
2014-02-10 21:59:35 -06:00
|
|
|
self.action = Some(WakeTask);
|
|
|
|
wait_until_woken_after(&mut self.blocker, &self.uv_loop(), || {
|
2014-04-18 15:23:56 -05:00
|
|
|
self.start(timer_cb, msecs, 0);
|
2013-11-20 17:46:49 -06:00
|
|
|
});
|
2013-11-04 16:03:32 -06:00
|
|
|
self.stop();
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
|
|
|
|
2014-03-09 16:58:32 -05:00
|
|
|
fn oneshot(&mut self, msecs: u64) -> Receiver<()> {
|
|
|
|
let (tx, rx) = channel();
|
2013-10-22 17:13:18 -05:00
|
|
|
|
2013-11-08 23:59:50 -06:00
|
|
|
// similarly to the destructor, we must drop the previous action outside
|
|
|
|
// of the homing missile
|
|
|
|
let _prev_action = {
|
|
|
|
let _m = self.fire_homing_missile();
|
2013-12-15 20:17:43 -06:00
|
|
|
self.id += 1;
|
2013-11-09 13:02:16 -06:00
|
|
|
self.stop();
|
2014-04-18 15:23:56 -05:00
|
|
|
self.start(timer_cb, msecs, 0);
|
2014-03-09 16:58:32 -05:00
|
|
|
mem::replace(&mut self.action, Some(SendOnce(tx)))
|
2013-11-08 23:59:50 -06:00
|
|
|
};
|
2013-11-01 11:36:21 -05:00
|
|
|
|
2014-03-09 16:58:32 -05:00
|
|
|
return rx;
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|
|
|
|
|
2014-03-09 16:58:32 -05:00
|
|
|
fn period(&mut self, msecs: u64) -> Receiver<()> {
|
|
|
|
let (tx, rx) = channel();
|
2013-11-01 11:36:21 -05:00
|
|
|
|
2013-11-08 23:59:50 -06:00
|
|
|
// similarly to the destructor, we must drop the previous action outside
|
|
|
|
// of the homing missile
|
|
|
|
let _prev_action = {
|
|
|
|
let _m = self.fire_homing_missile();
|
2013-12-15 20:17:43 -06:00
|
|
|
self.id += 1;
|
2013-11-09 13:02:16 -06:00
|
|
|
self.stop();
|
2014-04-18 15:23:56 -05:00
|
|
|
self.start(timer_cb, msecs, msecs);
|
2014-03-09 16:58:32 -05:00
|
|
|
mem::replace(&mut self.action, Some(SendMany(tx, self.id)))
|
2013-11-08 23:59:50 -06:00
|
|
|
};
|
2013-11-01 11:36:21 -05:00
|
|
|
|
2014-03-09 16:58:32 -05:00
|
|
|
return rx;
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-18 21:09:31 -05:00
|
|
|
extern fn timer_cb(handle: *uvll::uv_timer_t) {
|
2013-11-07 22:13:25 -06:00
|
|
|
let _f = ForbidSwitch::new("timer callback can't switch");
|
2013-11-01 13:13:22 -05:00
|
|
|
let timer: &mut TimerWatcher = unsafe { UvHandle::from_uv_handle(&handle) };
|
2013-11-01 11:36:21 -05:00
|
|
|
|
2013-11-01 12:26:43 -05:00
|
|
|
match timer.action.take_unwrap() {
|
2014-02-10 21:59:35 -06:00
|
|
|
WakeTask => {
|
|
|
|
let task = timer.blocker.take_unwrap();
|
2014-01-16 21:58:42 -06:00
|
|
|
let _ = task.wake().map(|t| t.reawaken());
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
std: Make std::comm return types consistent
There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:
Sender::try_send(t: T) -> bool
This method currently doesn't transmit back the data `t` if the send fails
due to the other end having disconnected. Additionally, this shares the name
of the synchronous try_send method, but it differs in semantics in that it
only has one failure case, not two (the buffer can never be full).
SyncSender::try_send(t: T) -> TrySendResult<T>
This method accurately conveys all possible information, but it uses a
custom type to the std::comm module with no convenience methods on it.
Additionally, if you want to inspect the result you're forced to import
something from `std::comm`.
SyncSender::send_opt(t: T) -> Option<T>
This method uses Some(T) as an "error value" and None as a "success value",
but almost all other uses of Option<T> have Some/None the other way
Receiver::try_recv(t: T) -> TryRecvResult<T>
Similarly to the synchronous try_send, this custom return type is lacking in
terms of usability (no convenience methods).
With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:
Sender::send(t: T) -> ()
Sender::send_opt(t: T) -> Result<(), T>
SyncSender::send(t: T) -> ()
SyncSender::send_opt(t: T) -> Result<(), T>
SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
Receiver::recv() -> T
Receiver::recv_opt() -> Result<T, ()>
Receiver::try_recv() -> Result<T, TryRecvError>
The notable changes made are:
* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
line with the SyncSender::send_opt method. An asychronous send only has one
failure case, unlike the synchronous try_send method which has two failure
cases (full/disconnected).
* Sender::send_opt returns the data back to the caller if the send is guaranteed
to fail. This method previously returned `bool`, but then it was unable to
retrieve the data if the data was guaranteed to fail to send. There is still a
race such that when `Ok(())` is returned the data could still fail to be
received, but that's inherent to an asynchronous channel.
* Result is now the basis of all return values. This not only adds lots of
convenience methods to all return values for free, but it also means that you
can inspect the return values with no extra imports (Ok/Err are in the
prelude). Additionally, it's now self documenting when something failed or not
because the return value has "Err" in the name.
Things I'm a little uneasy about:
* The methods send_opt and recv_opt are not returning options, but rather
results. I felt more strongly that Option was the wrong return type than the
_opt prefix was wrong, and I coudn't think of a much better name for these
methods. One possible way to think about them is to read the _opt suffix as
"optionally".
* Result<T, ()> is often better expressed as Option<T>. This is only applicable
to the recv_opt() method, but I thought it would be more consistent for
everything to return Result rather than one method returning an Option.
Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.
Closes #11527
2014-04-10 12:53:49 -05:00
|
|
|
SendOnce(chan) => { let _ = chan.send_opt(()); }
|
2013-12-15 20:17:43 -06:00
|
|
|
SendMany(chan, id) => {
|
std: Make std::comm return types consistent
There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:
Sender::try_send(t: T) -> bool
This method currently doesn't transmit back the data `t` if the send fails
due to the other end having disconnected. Additionally, this shares the name
of the synchronous try_send method, but it differs in semantics in that it
only has one failure case, not two (the buffer can never be full).
SyncSender::try_send(t: T) -> TrySendResult<T>
This method accurately conveys all possible information, but it uses a
custom type to the std::comm module with no convenience methods on it.
Additionally, if you want to inspect the result you're forced to import
something from `std::comm`.
SyncSender::send_opt(t: T) -> Option<T>
This method uses Some(T) as an "error value" and None as a "success value",
but almost all other uses of Option<T> have Some/None the other way
Receiver::try_recv(t: T) -> TryRecvResult<T>
Similarly to the synchronous try_send, this custom return type is lacking in
terms of usability (no convenience methods).
With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:
Sender::send(t: T) -> ()
Sender::send_opt(t: T) -> Result<(), T>
SyncSender::send(t: T) -> ()
SyncSender::send_opt(t: T) -> Result<(), T>
SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
Receiver::recv() -> T
Receiver::recv_opt() -> Result<T, ()>
Receiver::try_recv() -> Result<T, TryRecvError>
The notable changes made are:
* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
line with the SyncSender::send_opt method. An asychronous send only has one
failure case, unlike the synchronous try_send method which has two failure
cases (full/disconnected).
* Sender::send_opt returns the data back to the caller if the send is guaranteed
to fail. This method previously returned `bool`, but then it was unable to
retrieve the data if the data was guaranteed to fail to send. There is still a
race such that when `Ok(())` is returned the data could still fail to be
received, but that's inherent to an asynchronous channel.
* Result is now the basis of all return values. This not only adds lots of
convenience methods to all return values for free, but it also means that you
can inspect the return values with no extra imports (Ok/Err are in the
prelude). Additionally, it's now self documenting when something failed or not
because the return value has "Err" in the name.
Things I'm a little uneasy about:
* The methods send_opt and recv_opt are not returning options, but rather
results. I felt more strongly that Option was the wrong return type than the
_opt prefix was wrong, and I coudn't think of a much better name for these
methods. One possible way to think about them is to read the _opt suffix as
"optionally".
* Result<T, ()> is often better expressed as Option<T>. This is only applicable
to the recv_opt() method, but I thought it would be more consistent for
everything to return Result rather than one method returning an Option.
Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.
Closes #11527
2014-04-10 12:53:49 -05:00
|
|
|
let _ = chan.send_opt(());
|
2013-12-15 20:17:43 -06:00
|
|
|
|
|
|
|
// Note that the above operation could have performed some form of
|
|
|
|
// scheduling. This means that the timer may have decided to insert
|
|
|
|
// some other action to happen. This 'id' keeps track of the updates
|
|
|
|
// to the timer, so we only reset the action back to sending on this
|
|
|
|
// channel if the id has remained the same. This is essentially a
|
|
|
|
// bug in that we have mutably aliasable memory, but that's libuv
|
|
|
|
// for you. We're guaranteed to all be running on the same thread,
|
|
|
|
// so there's no need for any synchronization here.
|
|
|
|
if timer.id == id {
|
|
|
|
timer.action = Some(SendMany(chan, id));
|
|
|
|
}
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|
2013-11-01 11:36:21 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
impl Drop for TimerWatcher {
|
|
|
|
fn drop(&mut self) {
|
2013-11-08 23:59:50 -06:00
|
|
|
// note that this drop is a little subtle. Dropping a channel which is
|
|
|
|
// held internally may invoke some scheduling operations. We can't take
|
|
|
|
// the channel unless we're on the home scheduler, but once we're on the
|
|
|
|
// home scheduler we should never move. Hence, we take the timer's
|
|
|
|
// action item and then move it outside of the homing block.
|
|
|
|
let _action = {
|
|
|
|
let _m = self.fire_homing_missile();
|
|
|
|
self.stop();
|
2013-12-18 11:57:58 -06:00
|
|
|
self.close();
|
2013-11-08 23:59:50 -06:00
|
|
|
self.action.take()
|
|
|
|
};
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
mod test {
|
2013-11-06 13:03:11 -06:00
|
|
|
use std::rt::rtio::RtioTimer;
|
2013-11-07 17:13:06 -06:00
|
|
|
use super::super::local_loop;
|
2013-12-13 13:30:59 -06:00
|
|
|
use super::TimerWatcher;
|
2013-10-22 17:13:18 -05:00
|
|
|
|
|
|
|
#[test]
|
2013-11-06 13:03:11 -06:00
|
|
|
fn oneshot() {
|
2013-11-07 17:13:06 -06:00
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
|
|
|
let port = timer.oneshot(1);
|
|
|
|
port.recv();
|
|
|
|
let port = timer.oneshot(1);
|
|
|
|
port.recv();
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
2013-11-06 13:03:11 -06:00
|
|
|
fn override() {
|
2013-11-07 17:13:06 -06:00
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
|
|
|
let oport = timer.oneshot(1);
|
|
|
|
let pport = timer.period(1);
|
|
|
|
timer.sleep(1);
|
std: Make std::comm return types consistent
There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:
Sender::try_send(t: T) -> bool
This method currently doesn't transmit back the data `t` if the send fails
due to the other end having disconnected. Additionally, this shares the name
of the synchronous try_send method, but it differs in semantics in that it
only has one failure case, not two (the buffer can never be full).
SyncSender::try_send(t: T) -> TrySendResult<T>
This method accurately conveys all possible information, but it uses a
custom type to the std::comm module with no convenience methods on it.
Additionally, if you want to inspect the result you're forced to import
something from `std::comm`.
SyncSender::send_opt(t: T) -> Option<T>
This method uses Some(T) as an "error value" and None as a "success value",
but almost all other uses of Option<T> have Some/None the other way
Receiver::try_recv(t: T) -> TryRecvResult<T>
Similarly to the synchronous try_send, this custom return type is lacking in
terms of usability (no convenience methods).
With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:
Sender::send(t: T) -> ()
Sender::send_opt(t: T) -> Result<(), T>
SyncSender::send(t: T) -> ()
SyncSender::send_opt(t: T) -> Result<(), T>
SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
Receiver::recv() -> T
Receiver::recv_opt() -> Result<T, ()>
Receiver::try_recv() -> Result<T, TryRecvError>
The notable changes made are:
* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
line with the SyncSender::send_opt method. An asychronous send only has one
failure case, unlike the synchronous try_send method which has two failure
cases (full/disconnected).
* Sender::send_opt returns the data back to the caller if the send is guaranteed
to fail. This method previously returned `bool`, but then it was unable to
retrieve the data if the data was guaranteed to fail to send. There is still a
race such that when `Ok(())` is returned the data could still fail to be
received, but that's inherent to an asynchronous channel.
* Result is now the basis of all return values. This not only adds lots of
convenience methods to all return values for free, but it also means that you
can inspect the return values with no extra imports (Ok/Err are in the
prelude). Additionally, it's now self documenting when something failed or not
because the return value has "Err" in the name.
Things I'm a little uneasy about:
* The methods send_opt and recv_opt are not returning options, but rather
results. I felt more strongly that Option was the wrong return type than the
_opt prefix was wrong, and I coudn't think of a much better name for these
methods. One possible way to think about them is to read the _opt suffix as
"optionally".
* Result<T, ()> is often better expressed as Option<T>. This is only applicable
to the recv_opt() method, but I thought it would be more consistent for
everything to return Result rather than one method returning an Option.
Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.
Closes #11527
2014-04-10 12:53:49 -05:00
|
|
|
assert_eq!(oport.recv_opt(), Err(()));
|
|
|
|
assert_eq!(pport.recv_opt(), Err(()));
|
2013-11-07 17:13:06 -06:00
|
|
|
timer.oneshot(1).recv();
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
2013-11-06 13:03:11 -06:00
|
|
|
fn period() {
|
2013-11-07 17:13:06 -06:00
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
|
|
|
let port = timer.period(1);
|
|
|
|
port.recv();
|
|
|
|
port.recv();
|
2013-12-13 21:33:28 -06:00
|
|
|
let port2 = timer.period(1);
|
|
|
|
port2.recv();
|
|
|
|
port2.recv();
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|
|
|
|
|
2013-11-06 13:03:11 -06:00
|
|
|
#[test]
|
|
|
|
fn sleep() {
|
2013-11-07 17:13:06 -06:00
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
|
|
|
timer.sleep(1);
|
|
|
|
timer.sleep(1);
|
2013-11-06 13:03:11 -06:00
|
|
|
}
|
2013-11-07 22:13:25 -06:00
|
|
|
|
|
|
|
#[test] #[should_fail]
|
|
|
|
fn oneshot_fail() {
|
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
|
|
|
let _port = timer.oneshot(1);
|
|
|
|
fail!();
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test] #[should_fail]
|
|
|
|
fn period_fail() {
|
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
|
|
|
let _port = timer.period(1);
|
|
|
|
fail!();
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test] #[should_fail]
|
|
|
|
fn normal_fail() {
|
|
|
|
let _timer = TimerWatcher::new(local_loop());
|
|
|
|
fail!();
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn closing_channel_during_drop_doesnt_kill_everything() {
|
|
|
|
// see issue #10375
|
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
2013-12-03 18:44:16 -06:00
|
|
|
let timer_port = timer.period(1000);
|
2013-11-07 22:13:25 -06:00
|
|
|
|
2014-01-26 21:57:42 -06:00
|
|
|
spawn(proc() {
|
2014-01-30 16:28:36 -06:00
|
|
|
let _ = timer_port.recv_opt();
|
2014-01-26 21:57:42 -06:00
|
|
|
});
|
2013-11-07 22:13:25 -06:00
|
|
|
|
|
|
|
// when we drop the TimerWatcher we're going to destroy the channel,
|
|
|
|
// which must wake up the task on the other end
|
|
|
|
}
|
|
|
|
|
2013-11-08 23:59:50 -06:00
|
|
|
#[test]
|
|
|
|
fn reset_doesnt_switch_tasks() {
|
|
|
|
// similar test to the one above.
|
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
2013-12-03 18:44:16 -06:00
|
|
|
let timer_port = timer.period(1000);
|
2013-11-08 23:59:50 -06:00
|
|
|
|
2014-01-26 21:57:42 -06:00
|
|
|
spawn(proc() {
|
2014-01-30 16:28:36 -06:00
|
|
|
let _ = timer_port.recv_opt();
|
2014-01-26 21:57:42 -06:00
|
|
|
});
|
2013-11-08 23:59:50 -06:00
|
|
|
|
2014-01-30 16:28:36 -06:00
|
|
|
drop(timer.oneshot(1));
|
2013-11-08 23:59:50 -06:00
|
|
|
}
|
2013-11-09 13:02:16 -06:00
|
|
|
#[test]
|
|
|
|
fn reset_doesnt_switch_tasks2() {
|
|
|
|
// similar test to the one above.
|
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
2013-12-03 18:44:16 -06:00
|
|
|
let timer_port = timer.period(1000);
|
2013-11-09 13:02:16 -06:00
|
|
|
|
2014-01-26 21:57:42 -06:00
|
|
|
spawn(proc() {
|
2014-01-30 16:28:36 -06:00
|
|
|
let _ = timer_port.recv_opt();
|
2014-01-26 21:57:42 -06:00
|
|
|
});
|
2013-11-09 13:02:16 -06:00
|
|
|
|
|
|
|
timer.sleep(1);
|
|
|
|
}
|
2013-11-08 23:59:50 -06:00
|
|
|
|
2013-11-07 22:13:25 -06:00
|
|
|
#[test]
|
|
|
|
fn sender_goes_away_oneshot() {
|
|
|
|
let port = {
|
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
|
|
|
timer.oneshot(1000)
|
|
|
|
};
|
std: Make std::comm return types consistent
There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:
Sender::try_send(t: T) -> bool
This method currently doesn't transmit back the data `t` if the send fails
due to the other end having disconnected. Additionally, this shares the name
of the synchronous try_send method, but it differs in semantics in that it
only has one failure case, not two (the buffer can never be full).
SyncSender::try_send(t: T) -> TrySendResult<T>
This method accurately conveys all possible information, but it uses a
custom type to the std::comm module with no convenience methods on it.
Additionally, if you want to inspect the result you're forced to import
something from `std::comm`.
SyncSender::send_opt(t: T) -> Option<T>
This method uses Some(T) as an "error value" and None as a "success value",
but almost all other uses of Option<T> have Some/None the other way
Receiver::try_recv(t: T) -> TryRecvResult<T>
Similarly to the synchronous try_send, this custom return type is lacking in
terms of usability (no convenience methods).
With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:
Sender::send(t: T) -> ()
Sender::send_opt(t: T) -> Result<(), T>
SyncSender::send(t: T) -> ()
SyncSender::send_opt(t: T) -> Result<(), T>
SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
Receiver::recv() -> T
Receiver::recv_opt() -> Result<T, ()>
Receiver::try_recv() -> Result<T, TryRecvError>
The notable changes made are:
* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
line with the SyncSender::send_opt method. An asychronous send only has one
failure case, unlike the synchronous try_send method which has two failure
cases (full/disconnected).
* Sender::send_opt returns the data back to the caller if the send is guaranteed
to fail. This method previously returned `bool`, but then it was unable to
retrieve the data if the data was guaranteed to fail to send. There is still a
race such that when `Ok(())` is returned the data could still fail to be
received, but that's inherent to an asynchronous channel.
* Result is now the basis of all return values. This not only adds lots of
convenience methods to all return values for free, but it also means that you
can inspect the return values with no extra imports (Ok/Err are in the
prelude). Additionally, it's now self documenting when something failed or not
because the return value has "Err" in the name.
Things I'm a little uneasy about:
* The methods send_opt and recv_opt are not returning options, but rather
results. I felt more strongly that Option was the wrong return type than the
_opt prefix was wrong, and I coudn't think of a much better name for these
methods. One possible way to think about them is to read the _opt suffix as
"optionally".
* Result<T, ()> is often better expressed as Option<T>. This is only applicable
to the recv_opt() method, but I thought it would be more consistent for
everything to return Result rather than one method returning an Option.
Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.
Closes #11527
2014-04-10 12:53:49 -05:00
|
|
|
assert_eq!(port.recv_opt(), Err(()));
|
2013-11-07 22:13:25 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn sender_goes_away_period() {
|
|
|
|
let port = {
|
|
|
|
let mut timer = TimerWatcher::new(local_loop());
|
|
|
|
timer.period(1000)
|
|
|
|
};
|
std: Make std::comm return types consistent
There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:
Sender::try_send(t: T) -> bool
This method currently doesn't transmit back the data `t` if the send fails
due to the other end having disconnected. Additionally, this shares the name
of the synchronous try_send method, but it differs in semantics in that it
only has one failure case, not two (the buffer can never be full).
SyncSender::try_send(t: T) -> TrySendResult<T>
This method accurately conveys all possible information, but it uses a
custom type to the std::comm module with no convenience methods on it.
Additionally, if you want to inspect the result you're forced to import
something from `std::comm`.
SyncSender::send_opt(t: T) -> Option<T>
This method uses Some(T) as an "error value" and None as a "success value",
but almost all other uses of Option<T> have Some/None the other way
Receiver::try_recv(t: T) -> TryRecvResult<T>
Similarly to the synchronous try_send, this custom return type is lacking in
terms of usability (no convenience methods).
With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:
Sender::send(t: T) -> ()
Sender::send_opt(t: T) -> Result<(), T>
SyncSender::send(t: T) -> ()
SyncSender::send_opt(t: T) -> Result<(), T>
SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
Receiver::recv() -> T
Receiver::recv_opt() -> Result<T, ()>
Receiver::try_recv() -> Result<T, TryRecvError>
The notable changes made are:
* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
line with the SyncSender::send_opt method. An asychronous send only has one
failure case, unlike the synchronous try_send method which has two failure
cases (full/disconnected).
* Sender::send_opt returns the data back to the caller if the send is guaranteed
to fail. This method previously returned `bool`, but then it was unable to
retrieve the data if the data was guaranteed to fail to send. There is still a
race such that when `Ok(())` is returned the data could still fail to be
received, but that's inherent to an asynchronous channel.
* Result is now the basis of all return values. This not only adds lots of
convenience methods to all return values for free, but it also means that you
can inspect the return values with no extra imports (Ok/Err are in the
prelude). Additionally, it's now self documenting when something failed or not
because the return value has "Err" in the name.
Things I'm a little uneasy about:
* The methods send_opt and recv_opt are not returning options, but rather
results. I felt more strongly that Option was the wrong return type than the
_opt prefix was wrong, and I coudn't think of a much better name for these
methods. One possible way to think about them is to read the _opt suffix as
"optionally".
* Result<T, ()> is often better expressed as Option<T>. This is only applicable
to the recv_opt() method, but I thought it would be more consistent for
everything to return Result rather than one method returning an Option.
Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.
Closes #11527
2014-04-10 12:53:49 -05:00
|
|
|
assert_eq!(port.recv_opt(), Err(()));
|
2013-11-07 22:13:25 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn receiver_goes_away_oneshot() {
|
|
|
|
let mut timer1 = TimerWatcher::new(local_loop());
|
2014-01-30 16:28:36 -06:00
|
|
|
drop(timer1.oneshot(1));
|
2013-11-07 22:13:25 -06:00
|
|
|
let mut timer2 = TimerWatcher::new(local_loop());
|
|
|
|
// while sleeping, the prevous timer should fire and not have its
|
|
|
|
// callback do something terrible.
|
|
|
|
timer2.sleep(2);
|
|
|
|
}
|
|
|
|
|
|
|
|
#[test]
|
|
|
|
fn receiver_goes_away_period() {
|
|
|
|
let mut timer1 = TimerWatcher::new(local_loop());
|
2014-01-30 16:28:36 -06:00
|
|
|
drop(timer1.period(1));
|
2013-11-07 22:13:25 -06:00
|
|
|
let mut timer2 = TimerWatcher::new(local_loop());
|
|
|
|
// while sleeping, the prevous timer should fire and not have its
|
|
|
|
// callback do something terrible.
|
|
|
|
timer2.sleep(2);
|
|
|
|
}
|
2013-10-22 17:13:18 -05:00
|
|
|
}
|