[Concurrency] Add API stubs for Task

[ktoso]

Introduce minimal placeholders for Task and UnsafeContinuation to enable prototyping usage of the concurrency APIs.

edit: crasher resolved 👍

---

This currently crashes with: Assertion failed: (empty() && "explosion had values remaining when destroyed!"), function ~Explosion, file /Users/ktoso/code/swift-project/swift/lib/IRGen/Explosion.h, line 65., partial stack:

@DougGregor suggests the crash may be related to missing functionality that @nate-chandler is working on?

[ktoso]

@swift-ci please smoke test

[ktoso]

Will be unblocked by #34370

[ktoso]

@swift-ci please test

[ktoso]

@swift-ci please smoke test

[ktoso]

And we're green; I also added some small tests... nothing very exciting but better doc the expected look of the API via such anyway.

Please review and merge at will @DougGregor (I don't have merge powers btw, not sure if that's expected I think Dario from my team did have those powers hm 🤔)

[ktoso]

@swift-ci please test

[ktoso]

Also added runDetached, priority and task handles. This mostly reuses existing wording, but puts it into API docs.

Please have a look @DougGregor

More things coming soon -- was thinking in a separate PR tbh, but I can keep adding here if we want all the Task core primitives in one PR.

[ktoso]

@swift-ci please test

[DougGregor]

LGTM. My few comments can be addressed in a follow-up.

[DougGregor]

We should probably put an OpaquePointer or perhaps an AnyObject in here and make it frozen, because Task is a thin wrapper around a pointer to a task, which is a ref-counted entity.

[ktoso]

Ah true, will address in next PR 👍

[rjmccall]

It's swift ref-counted, you should use Builtin.NativeObject.

[rjmccall]

In the proposal this was just a namespace. If we're going to make it a type that's a generic reference to a task, I think that's useful, but we need to think about how this interacts with Handle. Maybe it's a class.

[ktoso]

The proposal indeed at first declared enum Task but also has a few struct Task but I guess those were always meant to be extension Task -- I guess it boils down to the primary question if one should be able to "touch" someone else's task ever at all.

We mentioned that if we allow Task.current one could potentially store or send it around; This interacts with things like task local storage and the deadline/timeout APIs...

Or should we stick to "task is a concept" and all interaction with it is via static functions? It is more correct I guess, i.e. we can then easily disallow any other task being able to set/get task local storage (if it was an API on the task object it could be abused).

So... back to namespace or there's reason to have it a class?

[DougGregor]

Should this go away?

[ktoso]

Ah damn, forgot cancelation!

Thanks Doug, will remove

[ktoso]

Actually... that's not clear yet!

The more I dug into this while writing up the proposal the more second thoughts I was having.

Pasing example semantics comparison for reference:

  let neverChecks: Task.Handle<String, Never> = Task.runDetached {
    // never checks cancellation
    // Task.sleep(.seconds(60)) // pretend being slow
    "ok"
  }
​
  // ----
​
  // Semantics A) Cancellation truly is only co-operative
  //              These semantics would argue FOR the existence of the non-throwing get()
  neverChecks.cancel() // we cancel immediately
  // get ALWAYS throws, i.e. we're expecting this to throw a CancellationError
  // but under Semantics A won't -- we're truly cooperative, and the task never
  // checked cancellation so in reality it is as if it wasn't cancelled.
  await try neverChecks.get()
  // because the task never checked cancellation, we get "ok here"
  // Semantics A conclusion: we should offer a non throwing get()
​
  // ----
​
  // Semantics B) Cancellation is eager on handles, hard and does NOT guarantee emitting the same error
  //              These semantics would argue AGAINST the existence of the non throwing get()
  neverChecks.cancel() // we cancel immediately
  await try neverChecks.get() // under "eager" B cancellation semantics this will immediately throw
  // even if the task still executed and completed successfully (because it never checked for cancellation!)
  // this would throw a CancellationError under Semantics B

I would argue semantics A is what people are meaningfully after, and it allows building more predictably on the tasks / handles. This would imply that we do need the non throwing get.

[ktoso]

Ended up addressing in here some of the comments @DougGregor mentioned.

[ktoso]

@swift-ci please test