type piracy of Base.schedule(t::Task)

[rfourquet]

It makes me a bit nervous, and also prevents packages depending on OpenTelemetryAPI to have proper precompilation, getting the following warning if I don't put `precompile(false):

   ** incremental compilation may be fatally broken for this module **

Is there any plan on not relying on type piracy?

[findmyway]

I'd like to, but can't find an alternative to automatically pass Context info into nested tasks at the time. One possible solution is to create a dedicated field in the Task object, or at least allow executing some hooks when scheduling each task. (I guess this is worth creating an issue in Julia?)

---

Some more words on type piracy here:

In OpenTelemetry, it mentioned the cross cutting concern. This means that we may have to use type piracy for many instrumentation implementations. Otherwise, we need to modify the upstream packages directly to allow injecting customized logic, JuliaWeb/HTTP.jl#608 for example.

[findmyway]

It seems a related issue is already opened: JuliaLang/julia#35757

Especially this comment: JuliaLang/julia#35757 (comment)

[raffopazzo]

I haven't taken a deep look at the code yet but would it be possible to at least move the type piracy outside of the API module? In my project I embed Julia in a C++ app and I implement a meter provider that passes measurements to the C++ layer so in cases like this there is no need for that code to be in the API module itself. Should the override be in SDK instead?

[findmyway]

I haven't taken a deep look at the code yet but would it be possible to at least move the type piracy outside of the API module? ... Should the override be in SDK instead?

Thanks! That's a good suggestion. I think it is doable. I'll give it a try and do some tests.

[pankgeorg]

@lamdor brought up https://github.com/vchuravy/ScopedValues.jl (and the respective JuliaLang/julia#50958 PR). These are inherited across tasks, so they could potentially serve this purpose.