You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsI-slowIssue: Problems and improvements with respect to performance of generated code.
If there is sufficient room on the Rust stack to run a particular foreign function then we don't need to switch stacks. Each scheduler has a native stack size so we just need the Rust segment to be larger than that (and they can be much larger).
At that point we can annotate specific functions in core with their required stack size. It could significantly reduce the number of stack switches we do.
The text was updated successfully, but these errors were encountered:
I remember thinking about this case a bit during my starter project last summer. This is definitely a feasible optimization, but you have to be careful(?) in the case where C calls back to Rust (what was once charmingly called "crust" functions).
A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsI-slowIssue: Problems and improvements with respect to performance of generated code.
If there is sufficient room on the Rust stack to run a particular foreign function then we don't need to switch stacks. Each scheduler has a native stack size so we just need the Rust segment to be larger than that (and they can be much larger).
At that point we can annotate specific functions in core with their required stack size. It could significantly reduce the number of stack switches we do.
The text was updated successfully, but these errors were encountered: