belm0

In 2004, a friend and I tried to do something along these lines, a structured system to remunerate open source developers (among producers of other types of digital works). I remember trying to pitch a presentation for one of the Debian conferences, and hoping to extend deb packages with the signed metadata. No one was interested-- mostly our fault, but also ahead of its time (no blockchain, and popular indexes like PyPI were just being born).

http://giftfile.org/documents/free_software_hackers_intro

I'm open, as always, to refining my understanding of what structured concurrency is, what various forms it takes on, and how it came about. I don't think it's so obvious that the article has misstated, however.

I was not-quite-intentionally using a broader notion of structured concurrency, including not only the initial concept (tie task hierarchy to code structure, propagate errors up the call + task stack), but also critical pieces that are built on top of that, notably cancel/timeout scopes [1]. I don't think these pieces had been assembled to form something powerful enough to make concurrency manageable, until about the time of Nathaniel J. Smith's articles and Python Trio.

I'm revising the text slightly, and adding a footnote:

> It achieves this in ways that seem subtle to us-- clearly so, since its utility didn't reach critical mass until around 2018†

> † While it's argued that the core concept of structured concurrency has existed in some libraries and languages prior to the recent boom, these lacked significant parts of the story for making concurrency manageable. One is powerful, ergonomic control of timeouts and cancellation-- itself dependent on structured concurrency. Another is striving for a program that follows structured concurrency as a whole, including direct and transient dependencies. Nathaniel J. Smith was first to piece this all together, with a set of articles, and corresponding Python Trio concurrency library.

Though I suspect this will welcome more controversy ;)

[1] https://vorpus.org/blog/timeouts-and-cancellation-for-humans...

Actually, there are advantages to embracing single-OS-thread programming. It's an incredibly efficient use of CPU resources, and you generally don't need explicit locking. Resulting programs are much easier to understand, maintain, and diagnose. (I work daily on a complex, soft real-time, production app written by a team of developers, and the code has no locks.)

This doesn't work well in practice, because part of structured concurrency (at least as Python Trio introduced it) is to have a sane story about cancellation and timeouts. There isn't a safe way to cancel an OS thread or process short of some prearranged handshaking-- the thread or process being wrapped certainly needs to cooperate.

Coroutines give you an easy way to manage cancellation. Essentially, any yield back to the scheduler is an opportunity to inject a cancel into the task. The code run within the task doesn't need to do anything special (beyond not starving the scheduler).