DConf '22 Talk: Structured Concurrency

[Sebastiaan Koppe]

On Thursday, 13 October 2022 at 19:54:31 UTC, Markk wrote:
> On Thursday, 13 October 2022 at 08:04:46 UTC, Sebastiaan Koppe 
> wrote:
>
>> I haven't looked into OpenMP at all, ...
>
> Perhaps I should clarify that my question was not so much about 
> the actual "manifestation" of OpenMP, but rather about the 
> underlying concepts. A large part of your talk presents the 
> benefits of structured programming over the "goto mess", as an 
> analog for the benefits of "Structured Concurrency" over 
> anything else. It is there on this conceptual level that I do 
> not see any innovation over 1997 OpenMP.
>
> I'm not so much talking about whether syntax is fashionable, or 
> the approach of a built-in compiler feature the right design 
> choice.

I see.

I don't know. But if I wanted to find out I would look into how 
OpenMP supports cancellation, error handling and/or composing of 
(custom) asynchronous algorithms.

`retry` is a good example that hits all three. It needs to be 
cancellable - so that it stops retrying and cancels any running 
task - and it needs to go into (custom) retry logic whenever the 
underlying task errors, restarting it until it hits the retry 
limit - however that is defined.

How would one write such a thing using OpenMP, supposing it 
doesn't exist?

Obviously that doesn't invalidate your claim that these ideas are 
nothing new. However, I am approaching this much more from a 
practical standpoint and not as a CS historian.

To me it seems - from my brief googling - that the 
Sender/Receivers model is a more low-level abstraction of 
asynchronous computation and allows more fine-grained control.

I don't know whether that counts as a new idea or not.

---

When researching for structured concurrency I found a book from 
the late 90's that mentioned unstructured concurrency. It nailed 
the definition.

So yes, these concepts definitely were around before. Although 
funnily enough, the book mentioned nothing of structured 
concurrency.