about summary refs log tree commit diff
path: root/src/libnative/lib.rs
AgeCommit message (Collapse)AuthorLines
2014-02-14extern mod => extern crateAlex Crichton-2/+2
This was previously implemented, and it just needed a snapshot to go through
2014-02-06Add some doc examples to lib{green,native}Alex Crichton-1/+28
"How do I start in libX" is a common question that I've seen, so I figured putting the examples in as many places as possible is probably a good idea.
2014-02-03native: Require all results are used and fix falloutAlex Crichton-1/+3
2014-01-16Fixing a typo: bookeeping -> bookkeepingDerek Chiang-3/+3
2014-01-15register snapshotsDaniel Micay-24/+0
2014-01-12Bump version to 0.10-preBrian Anderson-1/+1
2014-01-09auto merge of #11360 : huonw/rust/stack_bounds, r=alexcrichtonbors-1/+17
We just approximate with a 2MB stack for native::start.
2014-01-07doc: Add libgreen and libnative to the indexBrian Anderson-0/+3
2014-01-07std::rt: require known stack bounds for all tasks.Huon Wilson-1/+17
We just approximate with a 1 or 2 MB stack for native::start.
2014-01-06Register new snapshotsAlex Crichton-4/+1
2014-01-05Don't abort the process in native::startAlex Crichton-1/+2
If the main closure failed, then the `exit_code` variable would still be `None`, and the `unwrap()` was failing (triggering a process abort). This changes the `unwrap()` to an `unwrap_or()` in order to prevent process abort and detect when the native task failed.
2014-01-02Bump version to 0.9Brian Anderson-1/+1
2014-01-01Move task count bookeeping out of libstdAlex Crichton-8/+2
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-26Register new snapshotsAlex Crichton-1/+0
2013-12-25Test fixes and rebase conflictsAlex Crichton-8/+5
* vec::raw::to_ptr is gone * Pausible => Pausable * Removing @ * Calling the main task "<main>" * Removing unused imports * Removing unused mut * Bringing some libextra tests up to date * Allowing compiletest to work at stage0 * Fixing the bootstrap-from-c rmake tests * assert => rtassert in a few cases * printing to stderr instead of stdout in fail!()
2013-12-24green: Properly wait for main before shutdownAlex Crichton-10/+15
There was a race in the code previously where schedulers would *immediately* shut down after spawning the main task (because the global task count would still be 0). This fixes the logic by blocking the sched pool task in receving on a port instead of spawning a task into the pool to receive on a port. The modifications necessary were to have a "simple task" running by the time the code is executing, but this is a simple enough thing to implement and I forsee this being necessary to have implemented in the future anyway.
2013-12-24Test fixes and rebase problemsAlex Crichton-0/+2
Note that this removes a number of run-pass tests which are exercising behavior of the old runtime. This functionality no longer exists and is thoroughly tested inside of libgreen and libnative. There isn't really the notion of "starting the runtime" any more. The major notion now is "bootstrapping the initial task".
2013-12-24Finalize the green::Pool typeAlex Crichton-1/+4
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-24native: Add tests and cleanup entry pointsAlex Crichton-15/+41
This adds a few smoke tests associated with libnative tasks (not much code to test here anyway), and cleans up the entry points a little bit to be a little more like libgreen. The I/O code doesn't need much testing because that's all tested in libstd (with the iotest! macro).
2013-12-24native: Introduce libnativeAlex Crichton-0/+61
This commit introduces a new crate called "native" which will be the crate that implements the 1:1 runtime of rust. This currently entails having an implementation of std::rt::Runtime inside of libnative as well as moving all of the native I/O implementations to libnative. The current snag is that the start lang item must currently be defined in libnative in order to start running, but this will change in the future. Cool fact about this crate, there are no extra features that are enabled. Note that this commit does not include any makefile support necessary for building libnative, that's all coming in a later commit.