When LockToRecvOSThread is called the calling goroutine will be locked to the same thread as the goroutine receiving on ch,

There is in general no guarantee that any goroutine is currently “receiving on” ch. (For example, one might have just received a value and unparked.) How would you specify the behavior in that case?

More generally, though, I think this API is too channel-specific. There are also valid synchronization patterns one might want to use with a thread-local API that do not involve channels: for example, one could use an atomic.Value or sync.Mutex wrapping a queue of callbacks, along with a channel or sync.Cond that is closed or signaled when the queue becomes non-empty.

The problem with this approach is that the interaction of LockOSThread and channel send imposes a much greater performance penalty in the program than it would be expected from simply using a channel: normal use of a channel is fast because it doesn't involve the OS scheduler and the Go scheduler has special optimized paths for it. But when LockOSThread is involved both the full cost of Go scheduler and the full cost of the OS scheduler are paid every time a send on the channel happens.

Can you give some more detail on this? Would it be feasible to optimize the compiler and/or runtime to avoid this cost?

In your example of Delve, it's not obvious to me that forcing the event loop and the AST interpreter to share a thread will be an overall win. It means that while the AST interpreter is running the program will not pay attention to events. I'm concerned that the performance will not be as desired, and that the next step will be a request for some sort of goroutine prioritization.

That said, like @bcmills I don't think an API based on channels makes sense here. What about something more like

// A ThreadLocker permits multiple goroutines to be locked to a single thread.
// Values of type ThreadLocker must be obtained by calling MakeThreadLocker.
type ThreadLocker struct { /* unexported fields */ }

// MakeThreadLocker returns a new ThreadLocker.
func MakeThreadLocker() *ThreadLocker

// Lock the currently running goroutine to the ThreadLocker. If this is the first goroutine to be locked to
// this ThreadLocker, then the goroutine will be locked to the currently running thread, and the currently
// running thread will be associated with this ThreadLocker.
// Otherwise, the goroutine will be locked to the thread associated with this ThreadLocker,
// meaning that it will be immediately preempted, and that when the method returns the goroutine
// will be running on the thread.
// A thread associated with a ThreadLocker will only run goroutines locked to that thread;
// if there are no such goroutines ready to run, the thread will wait until one is available.
// This panics if the ThreadLocker was not created by MakeThreadLocker.
func (*ThreadLocker) Lock()

// Unlock the currently running goroutine from the ThreadLocker. The goroutine will be immediately
// preempted, and when the method returns the goroutine will be running on a different thread.
// If this is the last goroutine running on the associated thread, that thread will exit.
// The same happens when the last locked goroutine returns or calls Goexit.
// This panics if the current goroutine is not locked to this ThreadLocker.
func (*ThreadLocker) Unlock()

When LockToRecvOSThread is called the calling goroutine will be locked to the same thread as the goroutine receiving on ch,

There is in general no guarantee that any goroutine is currently “receiving on” ch. (For example, one might have just received a value and unparked.) How would you specify the behavior in that case?

It would wait until there is one. Other details of the behavior are in the "Behavior of LockToRecvOSThread" section.

More generally, though, I think this API is too channel-specific. There are also valid synchronization patterns one might want to use with a thread-local API that do not involve channels: for example, one could use an atomic.Value or sync.Mutex wrapping a queue of callbacks, along with a channel or sync.Cond that is closed or signaled when the queue becomes non-empty.

Nothing in this proposal, that I can see, prevents other synchronization from being used by goroutines locked to the same OS thread. The LockToRecvOSThread call is just a way to extend the OS thread lock to more goroutines. Also, I'm not particularly married to this specific API, as far as I am concerned it is just one of several reasonable ones.

The problem with this approach is that the interaction of LockOSThread and channel send imposes a much greater performance penalty in the program than it would be expected from simply using a channel: normal use of a channel is fast because it doesn't involve the OS scheduler and the Go scheduler has special optimized paths for it. But when LockOSThread is involved both the full cost of Go scheduler and the full cost of the OS scheduler are paid every time a send on the channel happens.

Can you give some more detail on this? Would it be feasible to optimize the compiler and/or runtime to avoid this cost?

See:

• runtime: big performance penalty with runtime.LockOSThread #21827
• runtime: unexpectedly large slowdown with runtime.LockOSThread #18023

I find the assessment in #18023 convincing.

In your example of Delve, it's not obvious to me that forcing the event loop and the AST interpreter to share a thread will be an overall win. It means that while the AST interpreter is running the program will not pay attention to events. I'm concerned that the performance will not be as desired, and that the next step will be a request for some sort of goroutine prioritization.

There is no parallelism between the even loop and the AST interpreter: the event loop only runs when the target process is running and the AST interpreter only runs when it isn't. I have experimented with running the event loop entirely inside the LockOSThread goroutine and I do get the expected performance improvement (as long as there is no AST interpreter, otherwise it will deadlock when it needs to communicate with it).

That said, like @bcmills I don't think an API based on channels makes sense here. What about something more like

This looks fine to me too.

I used to program in a system that let you arrange programs this way, and it was easy to end up with deadlocks, because the one "goroutine" in a thread was blocked in a system call and stopping the other from running (and maybe it was going to wake up the system call by its actions).

We designed LockOSThread to avoid this problem by making it a single goroutine.

If there are performance issues, it sounds like we should fix the runtime scheduler, not introduce new API that might lead to worse problems.

Would this opinion change if the performance issue was an inevitable consequence of the design of LockOSThread?

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

I made a simple experiment, I rewrote the benchmark of #21827 in go and a rough equivalent in C with pthreads. With Go, using a LockOSThread server I get 8µs per server request with C I get 5µs per ping/pong.

So there is some optimization that could be done in the scheduler (or in the channel implementation), but even assuming it could be as fast as the C implementation it would still be much slower than the version that does not use LockOSThread, which runs at 0.5µs per request.

It's unfortunate if LockOSThread has a performance problem, but the vast majority of programs don't need LockOSThread, and there are significant semantic problems with this, so it doesn't seem like we should do this.

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

I think it's worth pointing out that the system call server, which this is aiming to replace, is just as much prone to deadlocks. So this would replace slow deadlock prone code with fast deadlock prone code.
Also asynchronous preemption is a mitigating factor here, that didn't exist when LockOSThread was originally added to the language.

I think it's worth pointing out that the system call server, which this is aiming to replace, is just as much prone to deadlocks. So this would replace slow deadlock prone code with fast deadlock prone code.

That may be true, but debuggability is also a concern: today it is viable to use goroutine dumps and/or static or dynamic analyzers to diagnose a deadlock involving channel communication, whereas debugging the proposed API would require substantial new debugging tools.

That may be true, but debuggability is also a concern: today it is viable to use goroutine dumps and/or static or dynamic analyzers to diagnose a deadlock involving channel communication, whereas debugging the proposed API would require substantial new debugging tools.

I think detecting this already requires a substantial amount of application specific investigation. What you would see is the server goroutine blocked on a system call and one or more other goroutines waiting to to send on the server's channel.
This is normal, every time you look at the program you will see something like this, what you need to know is what's going to make the blocked syscall return and what the goroutines waiting for the server are going to do.
If anything it's going to be easier to determine which goroutines are waiting to run on the locked thread, compared to having to examine the caller frames of runtime.chansend.

No change in consensus, so declined.
— rsc for the proposal review group