This is in preparation for giving schedulers their own life cycle separate
from the kernel.
Tasks must be deleted before their scheduler thread, so we can't let the
scheduler exit before all its tasks have been cleaned up. In this scheme,
the scheduler will unregister tasks with the kernel when they are reaped,
then drop their ref on the task (there may still be others). When the task
ref count hits zero, the task will request to be unregistered from the
scheduler, which is responsible for deleting the task.
Instead of having the kernel tell the scheduler to exit, let the scheduler
decide when to exit. For now it will exit when all of its tasks are
unregistered.
Instead of joining on the scheduler threads, instead keep a count of active
schedulers. When there are no more schedulers raise a signal for the main
thread to continue.
This will be required once schedulers can be added and removed from the
running kernel.
At the moment there's not really any reason to be raising this signal,
since they schedulers wake up periodically anyway, but once we remove
the timer this will be how the schedulers know to exit.
When the kernel fails, kill all tasks and wait for the schedulers to stop
instead of just exiting. I'm sure there are tons of lurking issues here but
this is enough to fail without leaking (at least in the absence of cleanups).
This is the new way to refer to tasks in rust-land. Currently all they
do is serve as a key to look up the old rust_task structure. Ideally
they won't be ref counted, but baby steps.
Previously we were locking the spawning task's scheduler. I couldn't
see that that was protecting anything. The newborn_task list in the new task's
scheduler though was unprotected from concurrent access. So now we're locking
the new task's scheduler.
getenv is not threadsafe and (maybe as a result) it's randomly crashing with
CFLAGS=-g and RUST_THREADS=32. Calls from rust code are still on their
own.
Tasks are spawned on a random thread. Currently they stay there, but
we should add task migration and load balancing in the future. This
should drammatically improve our task performance benchmarks.
We're trying to get closer to doing correct move semantics for channel
operations. This involves a lot of cleanup (such as removing the
unused sched parameter from rust_vec constructor) and making
circular_buffer kernel_owned.
Added tagging for memory allocations. This means we give a string tag
to everything we allocate. If we leak something and TRACK_ALLOCATIONS
is enabled, then it's much easier now to tell exactly what is leaking.
