On 10/7/2019 1:46 PM, jab wrote:
Coming across https://trio.discourse.group/t/structured-concurrency-and-delimited-continuations/ just provoked me to search for discussion of structured concurrency in Racket. I didn’t immediately find much.* I hope that doesn’t mean that the interesting work that’s being discussed over in https://trio.discourse.group/c/structured-concurrency etc. has been largely unknown by the Racket community. Trio is having a profound impact on the future of concurrency, not just in Python but in many other languages. There’s even a post on Wikipedia now: https://en.wikipedia.org/wiki/Structured_concurrency (For anyone new to the term, https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ might be the best starting point. One persuasive example shows Nathaniel live coding a correct implementation of RFC 655 “Happy Eyeballs” in 40 lines of Python: https://github.com/python-trio/trio-talks/tree/master/njsmith-async-concurrency-for-mere-mortals (For comparison, Twisted’s implementation took hundreds of lines and still had a logic bug after years of work.) There is also some related reading in https://github.com/python-trio/trio/wiki/Reading-list.) I hope this post provokes discussion of structured concurrency in Racket. It’d be fascinating to read more of your thoughts! Thanks, Josh * For example, Googling “structured concurrency racket” turned up mostly just a brief mention of Racket’s custodians in the bottom-most comment on this post: http://250bpm.com/blog:71
"Structured concurrency" as defined by those articles really applies only to programs that operate in distinct phases - which is a pretty good description of many science programs - but such programs represent a (important, but) small subset of all parallel programs.
Racket's APIs are designed to support general parallelism, not just phased parallelism.
I suppose an argument could be made for syntax explicitly aimed at phased parallelism ... but using macros, such syntax could be built on top of the existing parallel (future, thread, place) APIs - so there is nothing stopping you, or anyone else, from creating a "structured concurrency" package that everyone can use.
One problem I foresee is defining a reasonable syntax and semantics. Most of the languages that promote "structured" concurrency have C-like syntax. Moreover they vary considerably in semantics - in some of them the spawning thread stops immediately and can't continue until its children exit, but other allow the spawning thread to continue until it executes an explicit join / wait for its children.
The Lisp/Scheme based idioms of S-expr Racket are very different from those of C-like languages, and whether or not some "Racket2" materializes having a more C-like syntax, many people like Racket just the way it is. I can envision heated debates about what should be the proper "structuring" semantics and what syntax best represents them.
YMMV, George -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/8b83ff75-7b57-f3f1-0514-46170c9c3141%40comcast.net.
