SE-0505: Delayed Enqueuing for Executors

[al45tair (Alastair Houghton)]

@johannesweiss

Concretely, the issue is that swift_task_enqueueGlobalWith* will consume resources in the executor that cannot be freed until the timer/deadline expires. To address this, the proposal should return a handle to the scheduled timer that can be discarded when no longer needed.

This is more of a general issue with executors as a whole though. There's no way presently to cancel a job, and jobs consume resources until the executor tries to run them; this isn't specific to jobs enqueued with a delay — it affects all jobs, including cancellable Tasks. I don't think we should hold up the delayed enqueuing proposal in order to fix that. Granted, that might mean some new APIs in the future.

I'm also not sure about all the mentions of swift_task_enqueueGlobalWith*. That API is being re-cored on top of this; it isn't the underlying implementation.

@Dmitriy_Ignatyev

Having Clock define methods for running executor jobs feels unintuitive to me. In the standard library today there are only two concrete clocks—ContinuousClock and SuspendingClock—and as a user I naturally expect a Clock API to be about time: instants, durations, measurement, and related concepts.

This was extensively discussed in two of the pitch threads. See for instance
[Pitch 2] Custom Main and Global Executors - #41 by John_McCall.

@Philippe_Hausler

The clock's instant has a duration type and that can differ from Duration.

The definition of Clock says:

public protocol Clock<Duration>: Sendable {
  associatedtype Duration
  associatedtype Instant: InstantProtocol where Instant.Duration == Duration
  ...

so no, Duration cannot differ from Instant.Duration.

@Philippe_Hausler

The protocol of SchedulingExecutor should really only have one entry point for scheduling, the deadline variant of executing at a specific instant. Not only is the math relatively easy to do

This also came up during the pitch phase. The reason for having both options in the protocol is that there are situations, particularly in embedded systems, where having to compute an instant is unnecessary overhead — in particular, reading a clock may not be a cheap operation — while they are able to easily wait for a duration.

It's also possible in some cases that, even on the same clock, the two operations are subtly different in character. For example, waiting for a duration might be immune to system clock changes, where waiting for an instant isn't.

There isn't a requirement to implement both of the methods, mind; if you implement one, the library code will do the mathematics to make the other one work.