summary refs log tree commit diff
path: root/src/libgreen/task.rs
AgeCommit message (Collapse)AuthorLines
2014-11-20Remove libgreenAaron Turon-602/+0
With runtime removal complete, there is no longer any reason to provide libgreen. [breaking-change]
2014-11-17Switch to purely namespaced enumsSteven Fackler-0/+3
This breaks code that referred to variant names in the same namespace as their enum. Reexport the variants in the old location or alter code to refer to the new locations: ``` pub enum Foo { A, B } fn main() { let a = A; } ``` => ``` pub use self::Foo::{A, B}; pub enum Foo { A, B } fn main() { let a = A; } ``` or ``` pub enum Foo { A, B } fn main() { let a = Foo::A; } ``` [breaking-change]
2014-11-08Runtime removal: fully remove rtioAaron Turon-9/+0
This patch cleans up the remnants of the runtime IO interface. Because this eliminates APIs in `libnative` and `librustrt`, it is a: [breaking-change] This functionality is likely to be available publicly, in some form, from `std` in the future.
2014-10-29Rename fail! to panic!Steve Klabnik-6/+6
https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change]
2014-10-24Print stack overflow messages for Windows, Linux and OS XJohn Kåre Alsaker-0/+7
Fixes #17562
2014-10-19Remove a large amount of deprecated functionalityAlex Crichton-5/+5
Spring cleaning is here! In the Fall! This commit removes quite a large amount of deprecated functionality from the standard libraries. I tried to ensure that only old deprecated functionality was removed. This is removing lots and lots of deprecated features, so this is a breaking change. Please consult the deprecation messages of the deleted code to see how to migrate code forward if it still needs migration. [breaking-change]
2014-10-01Remove all use of librustuvAaron Turon-1/+1
2014-08-28auto merge of #16664 : aturon/rust/stabilize-option-result, r=alexcrichtonbors-8/+8
Per API meeting https://github.com/rust-lang/meeting-minutes/blob/master/Meeting-API-review-2014-08-13.md # Changes to `core::option` Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues. However, a few methods have been deprecated, either due to lack of use or redundancy: * `take_unwrap`, `get_ref` and `get_mut_ref` (redundant, and we prefer for this functionality to go through an explicit .unwrap) * `filtered` and `while` * `mutate` and `mutate_or_set` * `collect`: this functionality is being moved to a new `FromIterator` impl. # Changes to `core::result` Most of the module is marked as stable or unstable; most of the unstable items are awaiting resolution of conventions issues. * `collect`: this functionality is being moved to a new `FromIterator` impl. * `fold_` is deprecated due to lack of use * Several methods found in `core::option` are added here, including `iter`, `as_slice`, and variants. Due to deprecations, this is a: [breaking-change]
2014-08-28Fallout from stabilizing core::optionAaron Turon-8/+8
2014-08-27Implement generalized object and type parameter bounds (Fixes #16462)Niko Matsakis-1/+3
2014-08-01Fix misspelled comments.Joseph Crail-1/+1
2014-07-30green: Prevent runtime corruption on spawn failureAlex Crichton-3/+18
Like with libnative, when a green task failed to spawn it would leave the world in a corrupt state where the local scheduler had been dropped as well as the local task. Also like libnative, this patch sets up a "bomb" which when it goes off will restore the state of the world.
2014-07-24libsyntax: Remove `~self` and `mut ~self` from the language.Patrick Walton-11/+13
This eliminates the last vestige of the `~` syntax. Instead of `~self`, write `self: Box<TypeOfSelf>`; instead of `mut ~self`, write `mut self: Box<TypeOfSelf>`, replacing `TypeOfSelf` with the self-type parameter as specified in the implementation. Closes #13885. [breaking-change]
2014-06-28auto merge of #15208 : alexcrichton/rust/snapshots, r=pcwaltonbors-2/+2
This change registers new snapshots, allowing `*T` to be removed from the language. This is a large breaking change, and it is recommended that if compiler errors are seen that any FFI calls are audited to determine whether they should be actually taking `*mut T`.
2014-06-28Rename all raw pointers as necessaryAlex Crichton-2/+2
2014-06-26rustrt: Reorganize task usageAlex Crichton-2/+2
Most of the comments are available on the Task structure itself, but this commit is aimed at making FFI-style usage of Rust tasks a little nicer. Primarily, this commit enables re-use of tasks across multiple invocations. The method `run` will no longer unconditionally destroy the task itself. Rather, the task will be internally re-usable if the closure specified did not fail. Once a task has failed once it is considered poisoned and it can never be used again. Along the way I tried to document shortcomings of the current method of tearing down a task, opening a few issues as well. For now none of the behavior is a showstopper, but it's useful to acknowledge it. Also along the way I attempted to remove as much `unsafe` code as possible, opting for safer abstractions.
2014-06-24librustc: Remove the fallback to `int` from typechecking.Niko Matsakis-1/+1
This breaks a fair amount of code. The typical patterns are: * `for _ in range(0, 10)`: change to `for _ in range(0u, 10)`; * `println!("{}", 3)`: change to `println!("{}", 3i)`; * `[1, 2, 3].len()`: change to `[1i, 2, 3].len()`. RFC #30. Closes #6023. [breaking-change]
2014-06-06libs: Fix miscellaneous fallout of librustrtAlex Crichton-20/+9
2014-05-11core: Remove the cast moduleAlex Crichton-4/+4
This commit revisits the `cast` module in libcore and libstd, and scrutinizes all functions inside of it. The result was to remove the `cast` module entirely, folding all functionality into the `mem` module. Specifically, this is the fate of each function in the `cast` module. * transmute - This function was moved to `mem`, but it is now marked as #[unstable]. This is due to planned changes to the `transmute` function and how it can be invoked (see the #[unstable] comment). For more information, see RFC 5 and #12898 * transmute_copy - This function was moved to `mem`, with clarification that is is not an error to invoke it with T/U that are different sizes, but rather that it is strongly discouraged. This function is now #[stable] * forget - This function was moved to `mem` and marked #[stable] * bump_box_refcount - This function was removed due to the deprecation of managed boxes as well as its questionable utility. * transmute_mut - This function was previously deprecated, and removed as part of this commit. * transmute_mut_unsafe - This function doesn't serve much of a purpose when it can be achieved with an `as` in safe code, so it was removed. * transmute_lifetime - This function was removed because it is likely a strong indication that code is incorrect in the first place. * transmute_mut_lifetime - This function was removed for the same reasons as `transmute_lifetime` * copy_lifetime - This function was moved to `mem`, but it is marked `#[unstable]` now due to the likelihood of being removed in the future if it is found to not be very useful. * copy_mut_lifetime - This function was also moved to `mem`, but had the same treatment as `copy_lifetime`. * copy_lifetime_vec - This function was removed because it is not used today, and its existence is not necessary with DST (copy_lifetime will suffice). In summary, the cast module was stripped down to these functions, and then the functions were moved to the `mem` module. transmute - #[unstable] transmute_copy - #[stable] forget - #[stable] copy_lifetime - #[unstable] copy_mut_lifetime - #[unstable] [breaking-change]
2014-05-06librustc: Remove `~EXPR`, `~TYPE`, and `~PAT` from the language, exceptPatrick Walton-23/+28
for `~str`/`~[]`. Note that `~self` still remains, since I forgot to add support for `Box<self>` before the snapshot. How to update your code: * Instead of `~EXPR`, you should write `box EXPR`. * Instead of `~TYPE`, you should write `Box<Type>`. * Instead of `~PATTERN`, you should write `box PATTERN`. [breaking-change]
2014-05-02Replace most ~exprs with 'box'. #11779Brian Anderson-2/+2
2014-04-19green: Fix missing Send bounds on proceduresAlex Crichton-5/+5
These were mistakenly not updated as part of the removal of the Send bound by default on procedures. cc #13629
2014-04-10std: Make std::comm return types consistentAlex Crichton-1/+1
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-03-31green: Switch field privacy as necessaryAlex Crichton-7/+7
2014-03-27Fix fallout of removing default boundsAlex Crichton-3/+2
This is all purely fallout of getting the previous commit to compile.
2014-03-24green: Remove the dependence on the crate mapAlex Crichton-1/+1
This is the final nail in the coffin for the crate map. The `start` function for libgreen now has a new added parameter which is the event loop factory instead of inferring it from the crate map. The two current valid values for this parameter are `green::basic::event_loop` and `rustuv::event_loop`.
2014-03-15log: Introduce liblog, the old std::loggingAlex Crichton-2/+1
This commit moves all logging out of the standard library into an external crate. This crate is the new crate which is responsible for all logging macros and logging implementation. A few reasons for this change are: * The crate map has always been a bit of a code smell among rust programs. It has difficulty being loaded on almost all platforms, and it's used almost exclusively for logging and only logging. Removing the crate map is one of the end goals of this movement. * The compiler has a fair bit of special support for logging. It has the __log_level() expression as well as generating a global word per module specifying the log level. This is unfairly favoring the built-in logging system, and is much better done purely in libraries instead of the compiler itself. * Initialization of logging is much easier to do if there is no reliance on a magical crate map being available to set module log levels. * If the logging library can be written outside of the standard library, there's no reason that it shouldn't be. It's likely that we're not going to build the highest quality logging library of all time, so third-party libraries should be able to provide just as high-quality logging systems as the default one provided in the rust distribution. With a migration such as this, the change does not come for free. There are some subtle changes in the behavior of liblog vs the previous logging macros: * The core change of this migration is that there is no longer a physical log-level per module. This concept is still emulated (it is quite useful), but there is now only a global log level, not a local one. This global log level is a reflection of the maximum of all log levels specified. The previously generated logging code looked like: if specified_level <= __module_log_level() { println!(...) } The newly generated code looks like: if specified_level <= ::log::LOG_LEVEL { if ::log::module_enabled(module_path!()) { println!(...) } } Notably, the first layer of checking is still intended to be "super fast" in that it's just a load of a global word and a compare. The second layer of checking is executed to determine if the current module does indeed have logging turned on. This means that if any module has a debug log level turned on, all modules with debug log levels get a little bit slower (they all do more expensive dynamic checks to determine if they're turned on or not). Semantically, this migration brings no change in this respect, but runtime-wise, this will have a perf impact on some code. * A `RUST_LOG=::help` directive will no longer print out a list of all modules that can be logged. This is because the crate map will no longer specify the log levels of all modules, so the list of modules is not known. Additionally, warnings can no longer be provided if a malformed logging directive was supplied. The new "hello world" for logging looks like: #[phase(syntax, link)] extern crate log; fn main() { debug!("Hello, world!"); }
2014-03-14green: Don't return the red zone in stack_bounds()Alex Crichton-3/+6
This is mostly just an implementation detail, and anyone worried about the stack bounds doesn't need to be bothered with the red zone because it's not usable anyway. Closes #12897
2014-03-13std: Rename Chan/Port types and constructorAlex Crichton-28/+27
* Chan<T> => Sender<T> * Port<T> => Receiver<T> * Chan::new() => channel() * constructor returns (Sender, Receiver) instead of (Receiver, Sender) * local variables named `port` renamed to `rx` * local variables named `chan` renamed to `tx` Closes #11765
2014-03-04Cleaned up `std::any`Marvin Löbel-0/+1
- Added `TraitObject` representation to `std::raw`. - Added doc to `std::raw`. - Removed `Any::as_void_ptr()` and `Any::as_mut_void_ptr()` methods as they are uneccessary now after the removal of headers on owned boxes. This reduces the number of virtual calls needed. - Made the `..Ext` implementations work directly with the repr of a trait object. - Removed `Any`-related traits from the prelude. - Added bench for `Any`
2014-02-24green,native,rustuv: Replace many pointer `transmute`'s with `as` or ↵Huon Wilson-1/+1
referencing. These can all be written in a more controlled manner than with the transmute hammer, leading to (hopefully) safer code.
2014-02-23std: Move raw to std::rawBrian Anderson-1/+1
Issue #1457
2014-02-16Clean up std::task docs, make TaskBuilder a real builderKevin Ballard-1/+0
Delete all the documentation from std::task that references linked failure. Tweak TaskBuilder to be more builder-like. .name() is now .named() and .add_wrapper() is now .with_wrapper(). Remove .watched() and .unwatched() as they didn't actually do anything.
2014-02-16Convert some unnecessary StaticNativeMutexes to NativeMutexes.Huon Wilson-10/+4
2014-02-16std: Rename unstable::mutex::Mutex to StaticNativeMutex.Huon Wilson-4/+4
This better reflects its purpose and design.
2014-02-16std: add an RAII unlocker to Mutex.Huon Wilson-2/+1
This automatically unlocks its lock when it goes out of scope, and provides a safe(ish) method to call .wait.
2014-02-13Remove two allocations from spawning a green taskAlex Crichton-45/+63
Two unfortunate allocations were wrapping a proc() in a proc() with GreenTask::build_start_wrapper, and then boxing this proc in a ~proc() inside of Context::new(). Both of these allocations were a direct result from two conditions: 1. The Context::new() function has a nice api of taking a procedure argument to start up a new context with. This inherently required an allocation by build_start_wrapper because extra code needed to be run around the edges of a user-provided proc() for a new task. 2. The initial bootstrap code only understood how to pass one argument to the next function. By modifying the assembly and entry points to understand more than one argument, more information is passed through in registers instead of allocating a pointer-sized context. This is sadly where I end up throwing mips under a bus because I have no idea what's going on in the mips context switching code and don't know how to modify it. Closes #7767 cc #11389
2014-02-13Don't require an allocation for on_exit messagesAlex Crichton-3/+2
Instead, use an enum to allow running both a procedure and sending the task result over a channel. I expect the common case to be sending on a channel (e.g. task::try), so don't require an extra allocation in the common case. cc #11389
2014-02-07Delete send_str, rewrite clients on top of MaybeOwned<'static>Kevin Ballard-1/+1
Declare a `type SendStr = MaybeOwned<'static>` to ease readibility of types that needed the old SendStr behavior. Implement all the traits for MaybeOwned that SendStr used to implement.
2014-02-03std: Remove try_send_deferred plus all falloutAlex Crichton-8/+5
Now that extra::sync primitives are built on a proper mutex instead of a pthreads one, there's no longer any use for this function.
2014-01-30Remove Times traitBrendan Zabarauskas-1/+1
`Times::times` was always a second-class loop because it did not support the `break` and `continue` operations. Its playful appeal was then lost after `do` was disabled for closures. It's time to let this one go.
2014-01-29Removing do keyword from libgreenScott Lawrence-16/+16
2014-01-09auto merge of #11360 : huonw/rust/stack_bounds, r=alexcrichtonbors-5/+6
We just approximate with a 2MB stack for native::start.
2014-01-07std::rt: require known stack bounds for all tasks.Huon Wilson-5/+6
We just approximate with a 1 or 2 MB stack for native::start.
2014-01-06Support arbitrary stdout/stderr/logger handlesAlex Crichton-1/+5
This will allow capturing of common things like logging messages, stdout prints (using stdio println), and failure messages (printed to stderr). Any new prints added to libstd should be funneled through these task handles to allow capture as well. Additionally, this commit redirects logging back through a `Logger` trait so the log level can be usefully consumed by an arbitrary logger. This commit also introduces methods to set the task-local stdout handles: * std::io::stdio::set_stdout * std::io::stdio::set_stderr * std::io::logging::set_logger These methods all return the previous logger just in case it needs to be used for inspection. I plan on using this infrastructure for extra::test soon, but we don't quite have the primitives that I'd like to use for it, so it doesn't migrate extra::test at this time. Closes #6369
2014-01-04Add a stack_bounds function to the Runtime traitAlex Crichton-0/+7
This allows inspection of the current task's bounds regardless of what the underlying task is. Closes #11293
2014-01-01Move task count bookeeping out of libstdAlex Crichton-3/+36
For libgreen, bookeeping should not be global but rather on a per-pool basis. Inside libnative, it's known that there must be a global counter with a mutex/cvar. The benefit of taking this strategy is to remove this functionality from libstd to allow fine-grained control of it through libnative/libgreen. Notably, helper threads in libnative can manually decrement the global count so they don't count towards the global count of threads. Also, the shutdown process of *all* sched pools is now dependent on the number of tasks in the pool being 0 rather than this only being a hardcoded solution for the initial sched pool in libgreen. This involved adding a Local::try_take() method on the Local trait in order for the channel wakeup to work inside of libgreen. The channel send was happening from a SchedTask when there is no Task available in TLS, and now this is possible to work (remote wakeups are always possible, just a little slower).
2013-12-24std: Remove must deferred sending functionsAlex Crichton-3/+8
These functions are all unnecessary now, and they only have meaning in the M:N context. Removing these functions uncovered a bug in the librustuv timer bindings, but it was fairly easy to cover (and the test is already committed). These cannot be completely removed just yet due to their usage in the WaitQueue of extra::sync, and until the mutex in libextra is rewritten it will not be possible to remove the deferred sends for channels.
2013-12-24green: Fixing all tests from previous refactoringsAlex Crichton-75/+86
2013-12-24rustuv: Write homing tests with SchedPoolAlex Crichton-9/+10
Use the previous commit's new scheduler pool abstraction in libgreen to write some homing tests which force an I/O handle to be homed from one event loop to another.