Selective receive is a feature supported in Erlang. It is for sure not available in programming models of other streaming systems. It pretty much gives you the expressive power of Kahn process networks.
The idea is that the receive-arms can be non-exhaustive so that we can select what we want to receive. In Arc-Script, selective receive is not currently possible since arms of a receive clause must be exhaustive. If it was possible we could do this:
task Foo() {
loop {
on A(x) => on B(y) => emit x + y
}
}
Motivation
The motivation for adding something like this is to enable more advanced event handling. An example is that you maybe have one stream producing input data for an ML model. Every 10min you selectively pull a mini-batch of events from this stream to train the model. After that you start pulling events one-by-one from another stream to make predictions.
Problem
The problem in Erlang is that the mailbox can grow large if events are not handled. In our case I think we should be able to handle this by having flow-control per-channel and arms without guards. This feature will probably be really difficult to implement, so I don't think we should dedicate any effort into implementing it for the time being.
Description
Selective receive is a feature supported in Erlang. It is for sure not available in programming models of other streaming systems. It pretty much gives you the expressive power of Kahn process networks.
The idea is that the receive-arms can be non-exhaustive so that we can select what we want to receive. In Arc-Script, selective receive is not currently possible since arms of a receive clause must be exhaustive. If it was possible we could do this:
Motivation
The motivation for adding something like this is to enable more advanced event handling. An example is that you maybe have one stream producing input data for an ML model. Every 10min you selectively pull a mini-batch of events from this stream to train the model. After that you start pulling events one-by-one from another stream to make predictions.
Problem
The problem in Erlang is that the mailbox can grow large if events are not handled. In our case I think we should be able to handle this by having flow-control per-channel and arms without guards. This feature will probably be really difficult to implement, so I don't think we should dedicate any effort into implementing it for the time being.