Hi Pontus,
Not all applications depend on all signals going forward. Sometimes only the latest data matters like for control applications. Older control values simply doesn't matter.
I agree that there are situations where intermediate states can be dropped. But there are other situations (think of a block-write request) where this must not happen. Therefore, the low-level mechanisms provided by Genode must support both.
I am wondering, do you feel the need to dispute Genode's low-level mechanisms at this point? They have been designed with great care for orthogonality, accountability, dependability, and performance over the course of the past 10 years while considering the wealth of use cases we encountered on our way towards general-purpose computing.
Please don't get me wrong. I don't want to dismiss your ideas. But I think that they can be realized on top of the existing low-level mechanisms (signals, RPC, shared memory) quite well. We don't need to change Genode to accommodate them. Should Genode's mechanisms become the bottleneck, I am of course open for changes. But this should be evidenced by real application scenarios first.
If you know the channel isn't failsafe that knowledge will have to be built into the application like it is for TCP/IP. My idea (taken from [1]) is to let asynchronous signals with data go via ring buffers. If these overflow you lose the oldest data and so it be. If a consumer is concerned with loosing data then just donate some additional ring buffer capacity to reduce the risk. Given that Genode can be finely tuned with respect to process priorities, CPU access slots and memory allocation this problem should not be very big.
For cases like this, which I would subsume as state propagation, I recommend you to consider the report and ROM session interfaces. The report session allows a component to export state in a non-blocking way whereas the ROM session allows a component to respond to and import external state.
The current packet stream does not allow for several consumers, only one from what I understand.
For the propagation of state from one producer to multiple consumers, please consider the report-ROM component, which represents a publisher-subscriber mechanism. It implicitly drops intermediate states if reports are produced at a higher rate than consumed (as ROMs). In principle, similar components could be created for other session interfaces such as the NIC session (for broadcasting NIC packets to many clients).
But likely only little need to be added to allow different consumers to have their own read pointers in a circular buffers.
Keeping this consumer-specific state is what Genode's sessions are for. E.g., for a NIC server with multiple clients, each session holds the read and write pointers for the respective client (the request queue and ack queue of the packet stream). Furthermore, the communication buffer is tied to the respective session, which answers the question of how to dimension and accounting it.
I am planning an example but not for the NIC loopback as it is too trivial to show on any advantages. The current line of work is to build the FSM from scratch to make better use of modern C++, avoid licensing issues and better integrate the solution with the existing signal mechanism. The idea is to allow for several cooperating FSMs to coexist in a protection domain that also can talk to FSMs in other components via the existing Genode communication infrastructure. An early prototype might be the loopback component, the real test is likely a new ip or udp stack layer.
This sounds interesting! If you have anything to show, I'd be delighted to have a look. :-)
Cheers Norman