Producer/consumer model for creating streams

[jclark]

In order to support event streams #440, we need to provide a producer/consumer model for creating streams. This requires a new abstraction, which I will call a queue: a producer strand (often started by a listener) can add to a queue; another strand can create stream from the queue, which it can use to process values added by producer strands to the queue.

These streams will typically be unbounded. One of the design challenges here is to ensure that queues can participate properly in a graceful shutdown.

[jclark]

Might be better to call this pipe.

On second thoughts, I think a better name is channel.

[jclark]

See ballerina-platform/ballerina-library#2821 (comment) for a discussion of why shutdown is difficult.

I think we want to approach this by seeing channels as the module-level counterpart of the worker message passing. Worker message passing is not design to maximize expressiveness. It's designed so that it can be fully analyzed, allowing for diagrams, static checking, and deadlock prevention. There's special syntax and named workers are not first-class, i.e. cannot be passed round as values.

[jclark]

Something like:

channel string demoChannel;

service /graphql on new graphql:Listener(4000) {
    resource function sub messages() returns stream<string> {
        // referencing the channel in an expression context produces a value of type stream<T> where
        // T is the member type of the channel
        return demoChannel;
    }
}

service / on new http:Listener(8080) {
    resource function post addMessage(string msg) returns string {
        msg -> demoChannel;
        return msg;
    }
}

Channels would not be allowed to be public, so you can completely analyze what's going on.

[jclark]

This ties into #736.

[jclark]

I suspect prohibiting public channels would be too restrictive. The challenge then is how to make things analyzable without this restriction.