-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
Issues with rust-level lock_and_signal #2781
Copy link
Copy link
Closed
Labels
A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Milestone
Metadata
Metadata
Assignees
Labels
A-runtimeArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsArea: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflowsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
The lock_and_signal implemented in libcore/sys.rs has two issues:
-- Easy solution: Add a preempt_disable counter in the rt scheduler, à la linux spinlocks, that it checks every yield
-- Hard solution: Make the scheduler know how to reschedule to the owner of a lock on the same core. (Still requires unkillable, I think)
fn lock(fn() -> T) -> Tis a cute interface, but doesn't support lock interleaving. Add acquire/release.