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
This is a proposal for runtime.ForEachOSThread and runtime.LockThreadAndDescendentsExclusive.
runtime.ForEachOSThread is of the form
package runtime
/* ForEachOSThread calls the provided closure on every operating system thread in the current process. The closure is executed with Go-level preemption disabled, guaranteeing that it has exclusive use of the corresponding OS thread while it is running. Calls to ForEachOSThread are serialized against each other within a process. Panics if it cannot fulfill its postconditions. */funcForEachOSThread(func () ()) ()
runtime.LockThreadAndDescendentsExclusive ensures that the current OS thread will be used exclusively by the current goroutine (and its descendants); furthermore, the current goroutine and its descendants will never be scheduled to any other OS thread, and the runtime will not create any other OS threads while executing on this one. This is intended for use with Linux namespaces.
The text was updated successfully, but these errors were encountered:
odeke-em
changed the title
Proposal: runtime.ForEachOSThread and runtime.LockThreadAndDescendentsExclusive
Proposal: runtime: add ForEachOSThread and LockThreadAndDescendentsExclusive
Dec 17, 2017
odeke-em
changed the title
Proposal: runtime: add ForEachOSThread and LockThreadAndDescendentsExclusive
proposal: runtime: add ForEachOSThread and LockThreadAndDescendentsExclusive
Dec 17, 2017
We aren't going to run arbitrary user code with preemption disabled. That is a footgun. We could perhaps run the code with runtime.LockOSThread called. But that leads directly to asking what we should do if some other goroutine has already called runtime.LockOSThread. Should we ignore that, and run this new code on there anyhow? Why is that reliably correct?
Locking a set of goroutines to a single thread is problematic because it's a considerable change to the scheduler. The support for locking a single goroutine to a thread appears all through the scheduler. Being able to lock a set of goroutines would presumably do the same. We would need a very good reason to add that level of complexity for a case that would presumably be very rarely used.
There's no way to implement ForEachOSThread. What if the thread is off doing something that can't be interrupted? More generally, we try hard to keep scheduling details from the programs, so they can't depend on them. This walks quite far in the wrong direction.
LockThreadAndDescendentsExclusive is at least doable but very complex, and we already have a very hard time keeping LockOSThread (single-goroutine version) working well.
This is a proposal for
runtime.ForEachOSThread
andruntime.LockThreadAndDescendentsExclusive
.runtime.ForEachOSThread
is of the formruntime.LockThreadAndDescendentsExclusive
ensures that the current OS thread will be used exclusively by the current goroutine (and its descendants); furthermore, the current goroutine and its descendants will never be scheduled to any other OS thread, and the runtime will not create any other OS threads while executing on this one. This is intended for use with Linux namespaces.The text was updated successfully, but these errors were encountered: