Let the compiler do memory layout computation for tasks at compile time#27
Let the compiler do memory layout computation for tasks at compile time#27michaelwoerister wants to merge 1 commit intosmol-rs:masterfrom
Conversation
instead of doing them manually at runtime.
|
I'm not sure this PR changes something that would make those MIRI tests fail. I'll look into Rust 1.39 support... |
|
Miri test fail is unrelated and will be fixed by matklad/once_cell#185. async-task/.github/workflows/ci.yml Line 81 in 8a886c2 As for MSRV, dropping Rust 1.39 support is fine, but there are currently no plans to drop support for Rust 1.48 used by Debian stable. See also #25. |
It looks like unions with non-copy fields were stabilized in 1.49. So close! I'll see if I can find another way to do this. |
|
Are there any downsides to using an |
|
I couldn't really get this to work in any satisfactory way. Miri rightfully kept complaining that taking the address of a field in potentially uninitialized memory is UB. I did get things to pass Miri at https://github.com/michaelwoerister/async-task/tree/raw-task-layout-experiment, and that seemed to also be a bit faster (15 instead of 19 nano seconds for I'll open an alternative PR that stores the minimal needed information for logical stack traces in the |
Let the compiler do memory layout computation for tasks at compile time instead of doing them manually at runtime.
Also note that it is advantageous for (crash dump) debugging to have an actual type that defines the layout, because that type will be described in debuginfo, which in turn allows debuggers to decode a task's raw memory blob. Without that type definiton, we cannot compute task layouts at runtime because debuginfo does not contain information about type alignments on all platforms.
Being able to decode raw task memory in debuggers is a prerequisite for eventually implementing logical stack traces.