[Returned for revision] SE-0472: Starting tasks synchronously from caller context

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

Thanks for the discussion John!

Yes, good point that the runtime trickery would end up doing the check twice. And that the nonisolated inference will get in the way... I keep forgetting about that interaction and it always ends up messing up those "don't hop" patterns.

@John_McCall

First off, I don't think the runtime should be playing much of a role here. The task function is an async function, and async functions are generally assumed to handle their own isolation. The caller doesn't need to (and generally should not) eagerly switch to the callee's isolation before making the call. It looks like you've got the runtime proactively deciding whether to run the initial task funclet synchronously or enqueue it, but I don't think that's really useful: regardless of what the runtime does, the first thing that that funclet's going to do is turn around and ask the runtime to switch to the right executor. The result is that you might as well just run the funclet synchronously, and it'll presumably make its executor request, and if that needs to suspend, it'll suspend and enqueue the task. The result is that you're essentially just forcing the executor check to be done twice. (You do need to run the initial funclet in a special runtime context that disallows switching executors on the current thread, though.)

I see what you're saying, ultimately all those things runtime may try to do before we run the task will be defeated by the nonisolated inference eventually anyway since it'll try to switch. Instead we need to adjust the inference and the switching behavior. The last example in your writeup indeed is how we'd blow up in this scheme. I was "lucky" while adapting the existing tests towards this new behavior in that the context and closure were both nonisolated or both isolated

Okey, so let's approach this by fixing the initial hop in those closure funclets instead.

I very much agree that fixing the inference rule to not require the explicit capturing here is even more important than in Task.init. Let's do that for this API and maybe if we'd manage to bring it to Task.init that'd be nice, but separate work.

So, there's a few cases now:

• the statically isolated to the same context as caller
  • the "new" isolation inference rule would take care of that; funclet just hops to that inferred isolation, notices it already is, we're good.
• the closure passed to Task.immediate is isolated to something ELSE than the dynamic caller isolation
  • this seems like it would just be taken care of by the task_switch as usual, we're on different than expected, so we'll enqueue.
  • we won't enqueue the task at first, but try to run it, task_switch would enqueue to target if it has to
• the current context has no executor at all, we're "dynamically nonisolated"
  • this is a new special case here; the first task_switch would have to recognize that's fine and just run inline, without hopping off to global pool; but subsequently do hop to that pool... we'd use some "fake" executor to signal this to the runtime probably.

Getting a bit into implementation weeds a bit much here, we can continue elsewhere, but it's been good to bring those up here a bit! Thanks!

I'm sure I missed some cases, but overall I think that'll work out -- and I'm very excited to "just" fix the isolation inference rule. That'll be a much welcomed win for understandability of this API.