Added conceptual documentation and general introduction #2140
Conversation
|
|
||
| #### Structured Concurrency | ||
|
|
||
| Formally-speaking, structured concurrency is a form of control flow in which all concurrent operations must form a closed hierarchy. Conceptually, it means that any operation which *forks* some actions to run concurrently must forcibly ensure that those actions are completed before moving forward. Furthermore, the *results* of a concurrent operation must only be made available upon its completion, and only to its parent in the hierarchy. `parTupled` above is a simple example of this: the `IO[(Response, Response)]` is unavailable as a result until *both* service calls have completed, and those responses are only accessible within the resulting tuple. |
There was a problem hiding this comment.
Since fork has not been used up to here, should we add a (start in Cats Effect) to maybe link the general concept to the actual implementation in CE?
There was a problem hiding this comment.
I struggled a lot with this paragraph. "Fork" in particular is difficult, because it's hard to define the concept without being circular. I'm not sure the implementation really helps, but I do agree this needs re-wording.
Co-authored-by: Vasil Vasilev <vasil@vasilev.io>
|
TIL, commit co-authoring. Handy. |
Says the guy who figured out how to co-author all of his tracing commits with @RaasAhsan… |
|
I did not actually, they are all authored solely by @RaasAhsan. I only committed them (even though in reality I also wrote them, because they needed a lot of changes since the underlying code had moved forward so much). |
|
I used |
No description provided.