While here, remove this now irrelevant comment.

Is it more precise to say "with the "cores" scheduler"?

This needs a more detailed description. For example, it doesn't say what happens if the target core is busy. I believeLockCore returns. If so, this is surprising to me; I would expect that onceLockCore returns, the calling goroutine is running on the target core.

Superfluous comment.

I think this should be a hard requirements; that is,LockCore should panic if any other goroutine has started.

Regarding "panic if goroutines started" - I have a specific use case for dynamic pinning:

Motion control board where:

Core 0: Communications and non-critical tasks
Core 1: Hard real-time step generation (must not be interrupted)
The pattern I need is:

func main() {
go func() {
machine.LockCore(1) // Pin worker to core 1
stepGenerationLoop()
}()
machine.LockCore(0) // Pin main to core 0
commsLoop()
}
If LockCore panics when goroutines have started, this pattern wouldn't work.

Would you accept one of these:

• Adding Gosched() in LockCore (so it actually migrates before returning)
• Keeping dynamic pinning allowed, with clear documentation of risks
• Perhaps a convention that each core should only have ONE pinned goroutine?

The deadlock risk is manageable if users follow the pattern of pinning early and using one goroutine per core for pinned work.

Adding Gosched() in LockCore (so it actually migrates before returning)

Yes, if we do thisLockCore should not return before the core is pinned.

However, given your use case: is it possible to run the step generation off a hardware timer and an interrupt handler? That seems a better fit, and you can keep both cores running non-critical code.

No, That is precisely the implementation that I am trying to get away from.

Can you elaborate why? Assuming yourstepGenerationLoop sometimes sleeps, it seems much less efficient to lock a core 100% of the time, even during sleeps than running an interrupt off a timer.

I see. I believe I'm doing something similar on a PIO-capable chip (rp2350). My solution is a 3-layer architecture:

• Regular Go code generates high-level primitives (line segments, bezier curves etc.) and sends them over a channel. This code is only timing sensitive to the extent that it needs to run often enough to not starve the interrupt handler. Depending on your application, you can get rid of the timing requirement by generating batches of primitives where each batch ends with the machine at a safe point (zero velocity/acceleration etc.).
• Interrupt handler receives from the channel and chops the primitives into fixed-duration updates and packs them into DMA buffers. For example, 2 steppers is 4 bits (2xdir, 2xstep) per update, and 8 updates per 32-bit PIO FIFO word.
  The interrupt handler is only timing sensitive insofar it must run often enough to fill the DMA buffers. If you don't have too much going on, you may not even need DMA and can get away with feeding the PIO FIFO buffer (8 words I believe) directly.
• A PIO state machine receives updates from its FIFO (fed directly or through DMA) and multiplex them onto the corresponding GPIO pins. The nature of PIOs makes the timing very robust and decoupled from the activity of the system, except for contention on the memory bus.

There is always multiple ways to skin a cat. I am using an approach similar to what you described as well. But having core pinning has its advantages as well. Also, It seems like several people have asked for it previously. Appreciate your reviews and responses

As one of the other people that have asked for pinning to cores, I'll chime in with my use case: I want to be able to dedicate a RP2040 (or 2350) core to realtime audio sample generation for agroovebox project. We are currently able to do this without issues using the RPI C SDK but the lack of core pinning prevents any attempt at trying to use tinyGo in the future for this or similar applications.

@maks your use case needsLockOSThread (lock to any core), not the more specificLockCore, right?

@eliasnaur sorry for slow reply. I'm new to Go so I'm unsure of how LockOSThread() is supposed to work for this context, but what I was after was to be able to run a Go routine on a specific core of a RP2040/2350 (eg. core1) and then have all other routines including main run on core0 only.