Show in-order processing patterns, equivalent to queue.async {} #69

ktoso · 2024-06-14T04:05:36Z

And that's not even half the story to be honest... there's even more advanced patterns which_do_ handle structured concurrency better... I'll leave at this example for now.

Future work here:

We could show the the AsyncProcessor that uses a "chain" of withCheckedThrowingContinuation and is more powerful than the async sequence approach but more complicated...
We could point at the upcoming language proposal of Task { [isolated self] in } but only once it's been accepted. https://github.com/sophiapoirier/swift-evolution/blob/closure-isolation/proposals/nnnn-closure-isolation-control.md

Overall I'd definitely like to include this somewhere here because it comes up all the time, but unsure about where exactly to put it. Open to opinions @mattmassicotte @hborla @xedin

resolves #22

Guide.docc/IncrementalAdoption.md

FranzBusch · 2024-06-14T08:32:17Z

Guide.docc/RuntimeBehavior.md

+Swift's concurrency model with a strong focus on async/await, actors and tasks,
+means that some patterns from other libraries or concurrency runtimes don't 
+translate directly into this new model. In this section, we'll explore common 
+patterns and differences in runtime behavior to be aware of, and how to address 
+them while you migrate your code to Swift concurrency.


I think runtime behaviour is a great article name but IMO we should talk about executors and executor jobs here first and how they relate to Tasks before we dive into implementing a specific pattern of ordered processing.

Sure, I'm not writing those in "final document order";

we'll do #59 which will explain executors, and it will be here; no worries.

FranzBusch · 2024-06-14T08:32:56Z

Guide.docc/RuntimeBehavior.md

+```
+
+This example **does not** guarantee anything about the order of the printed values,
+because Tasks are enqueued on a global (concurrent) threadpool which uses multiple


It would help if we spoke about executors here first IMO.

I've been thinking a lot about this. Many readers are going to be seeing these concepts for the first time. I find it easier to see concepts I work with in day-to-day code first, and then have access to lower-level details should I need them. Structuring these kinds of things is tricky. But, I think starting high-level and then moving lower could help offer more progressive disclosure. But, it also could make for a less organized document. So, I'm not sure what the correct trade-off is here, especally given that this is specifically about runtime behavior.

There's sections to be written about executors, that'd address this concern imho; it would not be in this section anyway

FranzBusch · 2024-06-14T08:36:10Z

Guide.docc/RuntimeBehavior.md

+The safest and correct way to enqueue a number of items to be processed by an actor,
+in a specific order is to use an `AsyncStream` to form a single, well-ordered
+sequence of items, which can be emitted to even from synchronous code.
+And then consume it using a _single_ task running on the actor, like this:


We have to call out here that this pattern is good to get order but it is potentially dangerous since it can queue up an unbounded amount of work. We should call this out here that AsyncStream has no external backpressure.

Ok, I can do a small note and direct to docs; there's a risk in too much information here, so I'll do just a short note on it

FranzBusch · 2024-06-14T08:36:47Z

Guide.docc/RuntimeBehavior.md

+        // Start consuming immediately, 
+        // or better have a caller of Printer call `startStreamConsumer()`
+        // which would make it run on the caller's task, allowing for better use of structured concurrency.
+        self.streamConsumer = Task { await self.consumeStream() }


Can we please not put spawning an unstructured task in this example here. Instead let's add a func run() async that consumes the stream. The users of this actor can then decide on what task to call that run method on.

It's explained below. I can inverse the order I guess

FranzBusch · 2024-06-14T08:37:14Z

Guide.docc/RuntimeBehavior.md

+//    between the producing and consuming task
+actor Printer {
+    let stream: AsyncStream<Int>
+    let streamContinuation: AsyncStream<Int>.Continuation


Doesn't this have to be nonisolated for the example to work?

I compiled this with Swift 6 mode, seems fine; I can double check again

FranzBusch · 2024-06-14T08:38:56Z

Guide.docc/RuntimeBehavior.md

+so we might need to resort to callbacks if we needed to report completion of an item
+getting processed.
+
+Notice that we kick off an unstructured task in the actor's initializer, to handle the


Ah we mentioned this down here. Can we just not show the unstructured task to begin with?

Guide.docc/RuntimeBehavior.md

mattmassicotte · 2024-06-14T10:47:22Z

Guide.docc/RuntimeBehavior.md

+Swift concurrency naturally enforces program order for asynchronous code as long
+as the execution remains in a single Task - this is equivalent to using "a single
+thread" to execute some work, but is more resource efficient because the task may
+suspend while waiting for some work, for example:


This sentence is quite long, can it be broken down?

Guide.docc/RuntimeBehavior.md

mattmassicotte · 2024-06-14T10:55:38Z

Guide.docc/RuntimeBehavior.md

+```
+
+This example **does not** guarantee anything about the order of the printed values,
+because Tasks are enqueued on a global (concurrent) threadpool which uses multiple


I've been thinking a lot about this. Many readers are going to be seeing these concepts for the first time. I find it easier to see concepts I work with in day-to-day code first, and then have access to lower-level details should I need them. Structuring these kinds of things is tricky. But, I think starting high-level and then moving lower could help offer more progressive disclosure. But, it also could make for a less organized document. So, I'm not sure what the correct trade-off is here, especally given that this is specifically about runtime behavior.

mattmassicotte · 2024-06-14T10:59:20Z

Guide.docc/RuntimeBehavior.md

+printer.enqueue(2)
+printer.enqueue(3)
+```
+


I think including a real init to make this syntatically valid, and then adding a swift will make this stand out less than it currently does.

mattmassicotte · 2024-06-14T10:59:44Z

Guide.docc/RuntimeBehavior.md

+printer.enqueue(2)
+printer.enqueue(3)
+```
+


same thing here - the lack of syntax highlighting really makes these stand out.

ok, will fix

Guide.docc/RuntimeBehavior.md

Co-authored-by: Matt Massicotte <[email protected]>

ktoso · 2024-07-03T13:22:08Z

Huh seems I didn't follow up here, will do :)

ankushkushwaha

Thanks for this documentation work. I appreciate it. Some typos and corrections I found.

ankushkushwaha · 2024-09-16T13:19:31Z

Guide.docc/RuntimeBehavior.md

+printer.enqueue(3)
+```
+
+In this case, you'd should make sure to only have at-most one task consuming the stream,


Suggested change

In this case, you'd should make sure to only have at-most one task consuming the stream,

In this case, you should make sure to only have at-most one task consuming the stream,

ankushkushwaha · 2024-09-16T13:21:45Z

Guide.docc/RuntimeBehavior.md

+We're assuming that the caller has to be in synchronous code, and this is why we make the `enqueue`
+method `nonisolated` but we use it to funnel work items into the actor's stream.
+
+The actor uses a single task to consume the async sequence of items, and this way guarantees


Suggested change

The actor uses a single task to consume the async sequence of items, and this way guarantees

The actor uses a single task to consume the async sequence of items, and this guarantees

ankushkushwaha · 2024-09-27T08:07:38Z

Can we resolve conflicts for this branch?

Show in-order processing patterns, equivalent to queue.async {}

c5c7945

ktoso requested review from hborla, mattmassicotte and shahmishal as code owners June 14, 2024 04:05

ktoso commented Jun 14, 2024

View reviewed changes

Guide.docc/IncrementalAdoption.md Outdated Show resolved Hide resolved

Make it a new file about RuntimeBehavior

68cab91

ktoso force-pushed the wip-show-in-order-processing-patterns branch from 7ef91aa to 68cab91 Compare June 14, 2024 04:19

FranzBusch reviewed Jun 14, 2024

View reviewed changes

mattmassicotte approved these changes Jun 14, 2024

View reviewed changes

ktoso and others added 3 commits June 14, 2024 20:09

Update Guide.docc/RuntimeBehavior.md

6791bf8

Co-authored-by: Matt Massicotte <[email protected]>

Apply suggestions from code review

fbb7f9d

Co-authored-by: Matt Massicotte <[email protected]>

Update Guide.docc/RuntimeBehavior.md

77824af

Co-authored-by: Matt Massicotte <[email protected]>

ankushkushwaha reviewed Sep 16, 2024

View reviewed changes

Vin757 approved these changes Sep 27, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Show in-order processing patterns, equivalent to queue.async {} #69

Show in-order processing patterns, equivalent to queue.async {} #69

ktoso commented Jun 14, 2024 •

edited

Loading

FranzBusch Jun 14, 2024

ktoso Jun 14, 2024

FranzBusch Jun 14, 2024

mattmassicotte Jun 14, 2024

ktoso Jun 14, 2024

FranzBusch Jun 14, 2024

ktoso Jun 14, 2024

FranzBusch Jun 14, 2024

ktoso Jun 14, 2024

FranzBusch Jun 14, 2024

ktoso Jun 14, 2024

FranzBusch Jun 14, 2024

mattmassicotte Jun 14, 2024

mattmassicotte Jun 14, 2024

mattmassicotte Jun 14, 2024

ktoso Jun 14, 2024

mattmassicotte Jun 14, 2024

ktoso Jun 14, 2024

ktoso commented Jul 3, 2024

ankushkushwaha left a comment

ankushkushwaha Sep 16, 2024

ankushkushwaha Sep 16, 2024

ankushkushwaha commented Sep 27, 2024

	In this case, you'd should make sure to only have at-most one task consuming the stream,
	In this case, you should make sure to only have at-most one task consuming the stream,

	The actor uses a single task to consume the async sequence of items, and this way guarantees
	The actor uses a single task to consume the async sequence of items, and this guarantees

Show in-order processing patterns, equivalent to queue.async {} #69

Are you sure you want to change the base?

Show in-order processing patterns, equivalent to queue.async {} #69

Conversation

ktoso commented Jun 14, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ktoso commented Jul 3, 2024

ankushkushwaha left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ankushkushwaha commented Sep 27, 2024

ktoso commented Jun 14, 2024 •

edited

Loading