Can we define this and all its other public API outside of the bridge area? Here in this file should be fine. Note we did similar for things like temporalio.runtime.BufferedMetric as a "protocol" (i.e. interface) noting that it had to match the Rust form of a bridge class impl. If there are things we need to work out with imports we can.

Yeah it's kind of pain because of circular import issues. I'll see if I can move it but I'm worried it means duping a bunch of stuff

Done

Can you help me understand this a bit? Looking at https://github.com/awestlake87/pyo3-asyncio/blob/master/src/tokio.rs I don't see where they are building a Tokio runtime w/ custom thread starter to add task locals for every thread. I wonder if we can just make/set the task locals with the event loop inside the one place they are needed later? The current event loop is available there too. I also see they use https://docs.rs/tokio/latest/tokio/macro.task_local.html, unsure if we could too.

They don't because I think it's built mostly on the assumption that it's Python calling into Rust and not the other way around, so any time and event loop is needed it already exists. That's not the case here, because we call into Python from whatever arbitrary thread in the Tokio runtime and that thread may not have any loop available on it, so we need to re-use the existing one (which also needs to be the same as the main one to avoid surprise issues with different loops trying to use things that were created on the main/another loop).

loop inside the one place they are needed later

What one place are you thinking of? Task locals are I think just going to mean we call this way more frequently than thread locals.

What one place are you thinking of?

Ah, yes, my mistake. So question, can any of these Python references information be captured and moved into the CustomSlotSupplierOfType? I admit I haven't dug into this, but I know I found in Ruby a way to keep "opaque" references that needed the GIL to use them, but were still Send/Sync so that I could move around (and they were prevented from being collected by Python while still having a reference in Rust).

If that's possible, I think we should put the TaskLocals on the CustomSlotSupplierOfType. Granted that assumes it's created with an event loop intact, but that should be an ok assumption I think. Actually, that's not something we should assume with Runtime now that I think about it.

Yeah, might be able to do that. I'll take a look

Done. Honestly not sure it's any better, really, but done regardless

True, though it is nice that it's worker specific and not actually setting any task locals

True, though it is nice that it's worker specific and not actually setting any task locals

I assume there is no value in allowing users to define this, at least not at this time.

No, there's not at the moment

If you'd rather, instead of logging and having a global logger, can call https://docs.python.org/3/library/warnings.html#warnings.warn instead. We do this in other places for should-not-happen things without relying on them setting up logging.

Decided not to do this since formatting for the user thrown exception is not nearly as nice w/ the stack trace not being shown whereas logging does