SE-0472: Starting tasks synchronously from caller context

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

@John_McCall

We may still want a warning for situations where this is statically impossible (or at least would only happen in improbable scenarios like two actors synchronizing), but we can let experience suggest whether that's actually important to diagnose.

So the signature in the proposal is specifically about the original pitched idea here: the "don't ever allow not synchronous execution", which is now being considered to change into "try to run synchronously". I was working out yesterday what the signature will have to become, and it seems it would be as follows:

@_implicitSelfCapture _ operation: __owned sending @isolated(any) @escaping () async throws -> Success

(which uncovered a but in interface printing, so we're working to fix that, while at it). We're not relying on the @_inheritActorContext here, but on comparing executor of current and target and doing the synchronous run if able to.

@John_McCall

The feature strongly discourages this by using @_inheritActorContext to align the isolations, so in theory it requires the programmer to use a non-closure as the task function (or give the closure an explicitly different isolation) in order to see surprising behavior.

In practice this would be these specific situations where we definitely change isolation:

@SomeActor 
func test() {
  Task.<immediately?> { @OtherActor in } // always enqueues
}

actor X {
  func test() {
    Task.<immediately?> { @OtherActor in } // always enqueues
  }
}

Here we statically know these must enqueue and won't be "immediate" / "start synchronous" ever. So I guess we could warn about it... I would not want to warn about situations where we're not 100% certain.

@John_McCall

That said, I do think there's a real problem here with the current @_inheritActorContext, because @_inheritActorContext doesn't inherit isolation if the outer context is isolated to a non-global actor which the closure doesn't capture. If I'm understanding correctly, this means that the closure will be inferred as non-isolated and therefore will never start immediately.

@John_McCall

We've talked elsewhere about whether this capture behavior is reasonable, but in this case I think it's clearly not, and we really ought to be forcing a capture so that we can inherit isolation properly.

There's two parts to talk about here:

One is that we can actually "start synchronously if not actually closed over any specific isolation" but it's a bit of an implementation hack:

Basically, if we use @isolated(any) and the closure is not isolated, its executor will be generic, then we check if the "target" isolation is generic, and if so, we just start synchronously immediately on the caller thread. The subsequent isolation / executor of that closure though, e.g. after we suspend and resume would be the generic executor then though. So we'd have the same semantics as Task{} but we would manage to start synchronously anyway. It's a bit of a hack since we interpret the "no specific isolation" as "ok to start on caller", but given that there's no way to enforce a closure to be nonisolated this actually kinda works I think.

I worked that out yesterday actually - you can check the impl here (pending a bug in sending checking).

The second topic is if that "forgot to close over isolated value / actor so therefore suddenly we execute on the global pool" is reasonable or not. Personally, I see a lot of people struggling with this and I'm more than sure that most developers don't realize this is the rule at all, so I'd love to fix it not only here but also for Task{} that "when created from context that is isolated, inherit that isolation".

IMHO, an ideal outcome would be that Task{} and this API would consistently just inherit the enclosing isolation and we'd be better off with less confusing language rule here overall.