This is a workaround for #1815. libev uses realloc(0) to
free the loop, which valgrind doesn't like. We have suppressions
to make valgrind ignore them.
Valgrind also has a sanity check when collecting allocation backtraces
that the stack pointer must be at least 512 bytes into the stack (at
least 512 bytes of frames must have come before). When this is not
the case it doesn't collect the backtrace.
Unfortunately, with our spaghetti stacks that valgrind check triggers
sometimes and we don't get the backtrace for the realloc(0), it
fails to be suppressed, and it gets reported as 0 bytes lost
from a malloc with no backtrace.
This fixes the issue by alloca'ing 512 bytes before calling uv_loop_delete
Allow class methods to have type parameters (this is a change from the
original classes proposal).
Add test cases for classes with type parameters, and classes with methods
that have their own type parameters.
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
from_maybe => get_with_default
maybe => with_option
may => with_option_do
I know these names are kind of ridiculous, but it's the best I could think of.
Feel free to bikeshed. Closes#2081
Previously two methods existed: rust_sched_loop::get_task and rust_task::get_task_from_tcb. Merge both of them into one, trying the faster one (tcb) first, and if that fails, the slower one from the tls.
Adds back the ability to make assertions about locks, but only under the
--enable-debug configuration
This reverts commit b247de6458.
Conflicts:
src/rt/rust_sched_loop.cpp
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.
rust_sched_launcher is actually responsible for setting up the thread and
starting the loop. There will be other implementations that do not actually
set up a new thread, in order to support scheduling tasks on the main OS
thread.
