Before the official concurrency proposal is presented I wanted to quickly sketch what I had on my mind on this topic:
Why not use Combine streams as channels between entities called
Reactors? More and more APIs get a
publisher method so a concurrency proposal could utilize that.
Reactors would have input and output
Ports which could be connected by streams. Once data arrives on an input port a reactor would proceed in its control flow possibly sending data to its output ports until it comes to a point where it waits for the next reaction.
This step wise processing is supported by specialized functions called
activities, which allow to wait for the next step via the
await statement. Normal functions and methods can be called from activities, but not the other way around.
Besides the capability to await the next instant, activities also support concurrent control-flows and preemption as in other imperative synchronous languages. The causality follows the Sequentially Constructive model and thus allows memory to be used as synchronization mechanism between concurrent trails (as opposed to using signals for synchronization like in Esterel).
In addition to the port based data-interface, reactors might also offer a functional API through
service methods. These methods would also have a stream based signature (at least for the return value) and internally spawn new reactors on each invocation to do the processing. The result of these service calls will be handled by a special statement available in activities called
So, the general idea is that of GALS - locally synchronous reactors which are asynchronously connected via Combine streams.