API change: rust_kernel::create_scheduler() or
rust_scheduler::rust_scheduler() respecitevly now take ownership of the
launch factory argument, it is needed to create new threads on demand.
Also renames rustrt::sched_threads() to rustrt::rust_sched_threads() for
consistency. Added rustrt::rust_max_sched_threads() to return the
maximal number of scheduled threads of the current scheduler.
Fixes#3493.
.. seeing an occasional valgrind/barf spew on some invalid read/writes..
need to investigate further.. i think its related to my poor citizen
conduct, re: pointers stashed in rust_kernel..
Many changes to code structure are included:
- removed TIME_SLICE_IN_MS
- removed sychronized_indexed_list
- removed region_owned
- kernel_owned move to kernel.h, task_owned moved to task.h
- global configs moved to rust_globals.h
- changed #pragma once to standard guard in rust_upcall.h
- got rid of memory.h
This just moves the responsibility for joining with scheduler threads
off to a worker thread. This will be needed when we allow tasks to be
scheduled on the main thread.
This makes the kernel join every scheduler thread before exiting in order to
ensure that all threads are completely terminated before the process exits. On
my machine, for 32-bit targets, this was causing regular valgrind errors.
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.
