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
There are probably a number of things needed to make this happen:
Scheduler:
Instead of reusing the scheduler's stack to call C code, we'll want each scheduler thread to hold a cache of big stacks, give each task a pointer to a C stack, a stack of C contexts and a stack of Rust contexts.
When calling into C code, if the task already has a C stack it reuses it, if not it checks whether the scheduler has any C stacks and pops one, or it allocates a new one, and pushes the Rust context onto the Rust context stack.
&c.
When it pops the last Rust context it returns the C stack to the scheduler's pool.
Language:
Would be really nice to be able to create functions with appropriate native signatures such that they could be called directly
Extensions:
Any glue that might be needed could be generated via a syntax extension.
The text was updated successfully, but these errors were encountered:
This is the best solution. However, there is a simpler variant that might be worth doing as a "first try": allow a subset of Rust code that is "non-blocking" and only allow C callbacks into that. This would probably take the form of requiring a "blocking" flag similar to "unsafe"... hmm... this is probably not worth the language complexity price. So, never mind, I think the idea is poor, but I will leave this comment for reference anyhow.
There are probably a number of things needed to make this happen:
Scheduler:
Language:
Extensions:
The text was updated successfully, but these errors were encountered: