Componolit / gneiss

Framework for platform-independent SPARK components
GNU Affero General Public License v3.0
22 stars 2 forks source link

Startup of event-driven components #9

Closed senier closed 5 years ago

senier commented 5 years ago

So far, we mainly supported the notion of programs with one Ada main loop that would do arbitrary things, sometimes block, sometimes poll for events. However, experience show that fully event-driven programs are much cleaner and performant. More importantly, when done right, such components avoid unnecessary state and back-pressure from clients. This is how components are supposed to be structured on Genode these days.

For Ada components following this pattern we need a couple of things:

We should review the existing block-device interface to meet this pattern. For Genode, we have to create a component (akin to libc/component.h) that allows for easy setup of such event-driven Ada components.

(This topic was migrated from the last comment of Componolit/ada-runtime#22 where it didn't belong).

jklmnn commented 5 years ago

With #11 all of those requirements should be implemented:

An interrupt-like mechanism to signal progress from the platform

For clients and servers that rely on incoming events an event handler needs to be provided that is called.

Interface to initialize a component and set up signal sources

Component initialization is done by calling initialize on a session object. The initialization can either happen in a main function that exists afterwards or in a event that is triggered by another session.

work in polling-mode upon reception of a signal

All event interfaces are implemented without passing data. This enables and forces polling.

allow for detecting the readiness of downstream components

Procedures are always expected to be successful. In the case of a semantic that can create an error a function is available that allows to poll the state until the procedure is guaranteed to succeed.

allow for rejecting a request if the component is not immediately ready to process it

Requests are not pushed to the receiver but provided by the sender. The receiver can then take a request if ready. In case of being unable to process a further request nothing happens. The sender is responsible of making sure it can provide more requests.

A strategy to implement that concept in an Ada main loop on platforms that do not directly support signals (e.g. Muen)

The use of procedures as generic parameters allows to build a main loop that calls all events. Instead of registering a signal a package is instantiated which then contains a user defined procedure that is called.

senier commented 5 years ago

Thanks, closing.