Bei LiIs this a good way to do simple debounce? Will Task creations take too much resources? š¤
Matt Massicotte@libei I bet there are pitfalls all over the place here. How about this:
@libei You know, you are right. Requring the AsyncSequence makes this more complexā¦
Ok back to this original, maybe just drop the detached and priority? Itās async, so you wonāt be blocking. Keep it real simple. You just have to make sure that cancel can actually stop the work in flight.
@mattiem This is what I'm actually want to achieve, store table view content offset to disk. I assume I should do file writing in detached task since it may be time consuming and blocking main thread.
In my experiments, this code snippet work good for debounce, I do only get the last result every time the table view scrolls.
Order seems good too since task creation and cancellation all happens on main actor.
My only concern is how much resource will cost by those task creations.
Jonathan Joelson@libei @mattiem Doesnāt `detached` mean there could potentially be multiple of these tasks executing concurrently? Imagine in the first task some hiccup causes JSON encoding to take 2 seconds and so the next task ācatches upā and writes the new offset, but then the first task overwrites that with the old value.
I think you should avoid `detached` so the tasks all run on the same actor. If you want this off-main then you could move the logic to your own `actor OffsetPersister`.
@jjoelson @libei the issue is the cancel is unable to stop that synchronous work. It would go like this:
- sleep completes
- big, slow sync operation *starts*
- new value comes in, cancel doesn't stop in-flight work
- new value isn't slow, gets written out
- finally the big slow sync completes, overwrites
@libei @mattiem Basically your original code, except itās all on a separate actor and no `detached`:
Ralph Waldo Pickle Chips@libei @jjoelson @mattiem I don't think it would be. Task.init's closure is marked @_inheritActorContext (https://github.com/apple/swift/blob/main/stdlib/public/Concurrency/Task.swift#L666), so after sleep returns, the actor is running the synchronous code in the task and anyone else calling update(offset:) would suspend until that's done. and Task.sleep checks for cancellation immediately after it unsuspends, so even if another update(offset:) call occurs while the current task is sleepingāand that new call executes first, before the synchronous code in the closureāthe current task will end early when it unsuspends
@shadowfacts @libei @mattiem Now Iām having doubts actually, because in order to call `update(offset:)` you need to do something like this in the UI, and as far as I know thereās no guarantee as to the ordering of these MainActor tasks if theyāre being generated very quickly by scroll events:
@jjoelson @shadowfacts @mattiem Even you somehow get these tasks executing in order, if I understand correctly, the actor has also no guarantee for the order of awaited `update(offset:)` calls.
> This is conceptually similar to a serial DispatchQueue, but with an important difference: tasks awaiting an actor are not guaranteed to be run in the same order they originally awaited that actor.
https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md#actor-isolation
@libei @shadowfacts @mattiem Iām starting to suspect thereās no way to do this with correctly with Swift Concurrency except by using AsyncStream š¤
@libei @shadowfacts @mattiem After some more thought, you can make it work with silliness like this, but at some point this is probably the wrong tool for the job.
@jjoelson @libei @shadowfacts Yeah I think you are probably right that if you want this off the main thread AND you want to guarantee the latest data is never overwritten you need a queue of some kind.
@mattiem @libei @shadowfacts You can generalize this beyond MainActor by making it an actor with `update(_:)` `nonisolated`. Iām actually coming around to this approach being Not That Badā¢.
