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.
Throwing in upcall_fail ends up running lots of code in the red zone. To avoid
it we have the personality function figure out which stack it's on and switch
as needed.
When unwinding through __morestack the stack limit in the TLS is invalidated
and must be reset. Instead of actually landing at __morestack we're
just going to make all our Rust landing pads call upcall_reset_stack_limit,
which will find the stack segment that corresponds to the current stack
pointer and put the limit in the TLS.
Also massively expand the stack segment red zone to make more room for the
dynamic linker. Will fix in the future.
When a task fails, we will throw an exception, then catch it at the bottom of
the stack.
On Windows we don't do this yet because the exception doesn't propagate
correctly.
No cleanups yet.
Issue #236
The motivation here is that the bottom of each stack needs to contain a C++
try/catch block so that we can unwind. This is already the case for main, but
not spawned tasks.
Issue #236
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.
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.
Ports and channels have been moved to the kernel pool, since they've
been known to outlive their associated task. This probably isn't the
right thing to do, the life cycle needs fixed instead.
Some refactorying in memory_region.cpp. Added a helper function to
increment and decrement the allocation counter. This makes it easier
to switch between atomic and non-atomic increments. Using atomic
increments for now, although this still does not fix the problem.
The callback happens when a task moves from the "blocked" state to the
"running" state. The callback is also inherited by child tasks. There
is currently only a native API.
This code hasn't been heavily exercised yet.
duplication, but we will hopefully drop the rustboot one soon.
This is also a preparation for changing the rustc one to have the activate glue
return to the exit glue which will then call the main function.
This (returning to the function that calls main) matches what happens when
loader stats a program or a new thread. It lets gdb produce good backtraces
and should help with EH too.
See https://github.com/graydon/rust/wiki/Logging-vision
The runtime logging categories are now treated in the same way as
modules in compiled code. Each domain now has a log_lvl that can be
used to restrict the logging from that domain (will be used to allow
logging to be restricted to a single domain).
Features dropped (can be brought back to life if there is interest):
- Logger indentation
- Multiple categories per log statement
- I possibly broke some of the color code -- it confuses me
