On Wed, 9 Oct 2019 16:15:14 -0400, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote:
>The Racket community, and even more so the design of Racket >concurrency APIs, is very strongly influenced by the academic side of >Racket. As far as I can tell, structured concurrency is fairly close >to what is traditionally called the fork/join model. To a 1st approximation. There are different implementations of fork/join. In some the forking thread stops immediately to wait for the spawned child(ren) to exit. In others, the forking thread can continue until it executes a deliberate join. But then there are systems where join implicitly targets all children. Then there are systems where join implicitly targets the last child forked and to wait for all children you have to keep executing join until it fails. Still others where (like with Unix processes) join implicitly targets a single child, but you don't know which one will return and to wait for all you have to keep executing joins. And still others where join can be told to wait for a particular set of children (ignoring others). Threads in Racket are signaling, and their completion (or death) can be detected using events or directly using their handles. So Racket can easily emulate any of the behaviors above. Putting a nicer syntax on it would just be some macrology. 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/neftpe5surndb67v0p2gqgrpklq8bq3jpf%404ax.com.
