summary refs log tree commit diff
path: root/src/libgreen/task.rs
AgeCommit message (Collapse)AuthorLines
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.
2013-12-24Finalize the green::Pool typeAlex Crichton-17/+31
The scheduler pool now has a much more simplified interface. There is now a clear distinction between creating the pool and then interacting the pool. When a pool is created, all schedulers are not active, and only later if a spawn is done does activity occur. There are four operations that you can do on a pool: 1. Create a new pool. The only argument to this function is the configuration for the scheduler pool. Currently the only configuration parameter is the number of threads to initially spawn. 2. Spawn a task into this pool. This takes a procedure and task configuration options and spawns a new task into the pool of schedulers. 3. Spawn a new scheduler into the pool. This will return a handle on which to communicate with the scheduler in order to do something like a pinned task. 4. Shut down the scheduler pool. This will consume the scheduler pool, request all of the schedulers to shut down, and then wait on all the scheduler threads. Currently this will block the invoking OS thread, but I plan on making 'Thread::join' not a thread-blocking call. These operations can be used to encode all current usage of M:N schedulers, as well as providing a simple interface through which a pool can be modified. There is currently no way to remove a scheduler from a pool of scheduler, as there's no way to guarantee that a scheduler has exited. This may be added in the future, however (as necessary).
2013-12-24green: Rip the bandaid off, introduce libgreenAlex Crichton-0/+505
This extracts everything related to green scheduling from libstd and introduces a new libgreen crate. This mostly involves deleting most of std::rt and moving it to libgreen. Along with the movement of code, this commit rearchitects many functions in the scheduler in order to adapt to the fact that Local::take now *only* works on a Task, not a scheduler. This mostly just involved threading the current green task through in a few locations, but there were one or two spots where things got hairy. There are a few repercussions of this commit: * tube/rc have been removed (the runtime implementation of rc) * There is no longer a "single threaded" spawning mode for tasks. This is now encompassed by 1:1 scheduling + communication. Convenience methods have been introduced that are specific to libgreen to assist in the spawning of pools of schedulers.