Why not []io.Closer?
What are the concurrent scenarios we are trying to protect against?

The Uprobe.Close is called by the Manager which can shutdown asynchronously. For example, this can occur when the context passed to the new Instrumentation is canceled asynchronously¹. This is to prevent that data-race.

I see. Do you think we can use sync.Once instead? I think it might be more readable

Using sync.Once would mean we need two fields here. One for the sync.Once and the other to hold the closer slice. I think having a single field is cleaner. It does not require a user to understand the implicit coupling between two fields and avoids the error case when they are not correctly handled.

Alternatively, we could use a sync.OnceFunc as a single field. However, this would leave a data-race when trying to replace the "swap" functionality. We would want to check if the "close" field is non-nil before assigning to it in load. This would need a semaphore to ensure no data-race, and again mean we require two fields.

It may also be tempting to not implement the "swap" functionality. That way we would just assign blindly on load and hope for the best on close (meaning there would be a data-race there). However, data-race asside, that would mean we no longer support instrumentation shutdown and then restarting, or probe unloading and reloading.

We could also use atomic.Value here. That was explored, but decided against due to the lack of type safety and the inability to set a value of nil (representing a state of stopped) without a panic.

Should we also add package constraints on the auto sdk probes?

I think we want to always add uprobes for auto/sdk. If that package is loaded, it may be because the user has done so explicitly and we don't want to not instrument it because of the version of otel. It also doesn't add runtime overhead if it is not used given the uprobe break-point is never triggered.

I see. Do you think we can use sync.Once instead? I think it might be more readable