Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: runtime: add ForEachOSThread and LockThreadAndDescendentsExclusive #23160

Closed
DemiMarie opened this issue Dec 17, 2017 · 2 comments
Closed

Comments

@DemiMarie
Copy link

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. */
func ForEachOSThread(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.

@gopherbot gopherbot added this to the Proposal milestone Dec 17, 2017
@odeke-em odeke-em changed the title Proposal: runtime.ForEachOSThread and runtime.LockThreadAndDescendentsExclusive Proposal: runtime: add ForEachOSThread and LockThreadAndDescendentsExclusive Dec 17, 2017
@odeke-em odeke-em changed the title Proposal: runtime: add ForEachOSThread and LockThreadAndDescendentsExclusive proposal: runtime: add ForEachOSThread and LockThreadAndDescendentsExclusive Dec 17, 2017
@ianlancetaylor
Copy link
Contributor

First, what problem is this intended to solve?

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.

@rsc
Copy link
Contributor

rsc commented Jan 29, 2018

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.

@rsc rsc closed this as completed Jan 29, 2018
@golang golang locked and limited conversation to collaborators Jan 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants