Hi,
During FOSDEM, one of the discussions touched on the components' handling of incoming RPC calls. Currently this is done in a synchronous manner because (if I remember correctly) it was simply easier to implement it that way as opposed to handling it asynchronously.
What would be some of the challenges in handling this asynchronously? It was mentioned that the RPC mechanism was tightly integrated with the whole codebase, so it would require a large refactor. I am curious to hear your thoughts on how supporting asynchronous RPC calls could impact the following:
- preservation of determinism (in the context of formal verification) - would the capability model need to be reworked to support revoking in-flight RPC requests? If so how could a client component signal to the server that it should drop the request?
I don't mean to argue for replacing the current model, I'm just interested learning a bit more about the design trade-offs :)
Best, Rumen
Hello Rumen,
On 2026-03-31 23:33, Rumen Mitov via users wrote:
During FOSDEM, one of the discussions touched on the components' handling of incoming RPC calls. Currently this is done in a synchronous manner because (if I remember correctly) it was simply easier to implement it that way as opposed to handling it asynchronously.
What would be some of the challenges in handling this asynchronously?
This was implemented in very early versions of Genode [1]. A few traces of these days still slumber in the (private-API) interface [2]. Those bits are needed on the original L4 kernels to implement asynchronous notification as a service in Genode's core.
[1] https://genode.org/documentation/release-notes/10.02#Out-of-order_RPC_replie... [2] https://github.com/genodelabs/genode/blob/master/repos/base/include/base/rpc...
However, the out-of-order handling of RPCs is a can of worms, which is nicely illustrated by [3].
[3] https://genode.org/documentation/release-notes/10.02#Challenges
Eventually, we realized that we had needed out-of-order RPCs merely to accommodate the notion of *blocking* RPC calls. E.g., the timer's msleep used to be implemented that way. Once we identified blocking RPCs as an anti-pattern, we changed the RPC interfaces to become non-blocking by combining synchronous (but non-blocking) RPC with asynchronous notifications [4]. SO for the timer, there is now way to set an alarm (RPC), a way to take a look at the current time (RPC), and a way to receive an alarm (asynchronous notification).
[4] https://genode.org/documentation/release-notes/13.02#Timer_interface_turned_...
You may also find [5] worth reading to get a feel for the evolution of Genode's current design.
[5] https://genode.org/documentation/release-notes/16.11#Asynchronous_parent-chi...
Today, you should no longer find any blocking RPC throughout Genode. Hence, we can nicely define the need for out-of-order RPCs away.
Some problems are best solved by not having them. ;-)
Should the motivation behind your question be unrelated to the problem of blocking RPCs, I'd very much appreciate to learn more about your ambition for stepping away from synchronous RPC.
Cheers Norman
Hi Norman,
Thank you for the comprehensive response! It cleared up the misconceptions I had about the RPC inner workings and it was interesting to see how the mechanism evolved over the years.
Best, Rumen
________________________________________ From: Norman Feske via users users@lists.genode.org Sent: Thursday, April 2, 2026 10:41 AM To: users@lists.genode.org Cc: Norman Feske Subject: Re: Async Handling of RPC Entrypoints
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hello Rumen,
On 2026-03-31 23:33, Rumen Mitov via users wrote:
During FOSDEM, one of the discussions touched on the components' handling of incoming RPC calls. Currently this is done in a synchronous manner because (if I remember correctly) it was simply easier to implement it that way as opposed to handling it asynchronously.
What would be some of the challenges in handling this asynchronously?
This was implemented in very early versions of Genode [1]. A few traces of these days still slumber in the (private-API) interface [2]. Those bits are needed on the original L4 kernels to implement asynchronous notification as a service in Genode's core.
[1] https://genode.org/documentation/release-notes/10.02#Out-of-order_RPC_replie... [2] https://github.com/genodelabs/genode/blob/master/repos/base/include/base/rpc...
However, the out-of-order handling of RPCs is a can of worms, which is nicely illustrated by [3].
[3] https://genode.org/documentation/release-notes/10.02#Challenges
Eventually, we realized that we had needed out-of-order RPCs merely to accommodate the notion of *blocking* RPC calls. E.g., the timer's msleep used to be implemented that way. Once we identified blocking RPCs as an anti-pattern, we changed the RPC interfaces to become non-blocking by combining synchronous (but non-blocking) RPC with asynchronous notifications [4]. SO for the timer, there is now way to set an alarm (RPC), a way to take a look at the current time (RPC), and a way to receive an alarm (asynchronous notification).
[4] https://genode.org/documentation/release-notes/13.02#Timer_interface_turned_...
You may also find [5] worth reading to get a feel for the evolution of Genode's current design.
[5] https://genode.org/documentation/release-notes/16.11#Asynchronous_parent-chi...
Today, you should no longer find any blocking RPC throughout Genode. Hence, we can nicely define the need for out-of-order RPCs away.
Some problems are best solved by not having them. ;-)
Should the motivation behind your question be unrelated to the problem of blocking RPCs, I'd very much appreciate to learn more about your ambition for stepping away from synchronous RPC.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
_______________________________________________ users mailing list -- users@lists.genode.org To unsubscribe send an email to users-leave@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/mes...
Is there a formal distinction between a blocking RPC and a non-blocking one, other than the expected time that will be taken?
On Thu, Apr 2, 2026, at 1:41 AM, Norman Feske via users wrote:
Hello Rumen,
On 2026-03-31 23:33, Rumen Mitov via users wrote:
During FOSDEM, one of the discussions touched on the components' handling of incoming RPC calls. Currently this is done in a synchronous manner because (if I remember correctly) it was simply easier to implement it that way as opposed to handling it asynchronously.
What would be some of the challenges in handling this asynchronously?
This was implemented in very early versions of Genode [1]. A few traces of these days still slumber in the (private-API) interface [2]. Those bits are needed on the original L4 kernels to implement asynchronous notification as a service in Genode's core.
[1] https://genode.org/documentation/release-notes/10.02#Out-of-order_RPC_replie... [2] https://github.com/genodelabs/genode/blob/master/repos/base/include/base/rpc...
However, the out-of-order handling of RPCs is a can of worms, which is nicely illustrated by [3].
[3] https://genode.org/documentation/release-notes/10.02#Challenges
Eventually, we realized that we had needed out-of-order RPCs merely to accommodate the notion of *blocking* RPC calls. E.g., the timer's msleep used to be implemented that way. Once we identified blocking RPCs as an anti-pattern, we changed the RPC interfaces to become non-blocking by combining synchronous (but non-blocking) RPC with asynchronous notifications [4]. SO for the timer, there is now way to set an alarm (RPC), a way to take a look at the current time (RPC), and a way to receive an alarm (asynchronous notification).
[4] https://genode.org/documentation/release-notes/13.02#Timer_interface_turned_...
You may also find [5] worth reading to get a feel for the evolution of Genode's current design.
[5] https://genode.org/documentation/release-notes/16.11#Asynchronous_parent-chi...
Today, you should no longer find any blocking RPC throughout Genode. Hence, we can nicely define the need for out-of-order RPCs away.
Some problems are best solved by not having them. ;-)
Should the motivation behind your question be unrelated to the problem of blocking RPCs, I'd very much appreciate to learn more about your ambition for stepping away from synchronous RPC.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
users mailing list -- users@lists.genode.org To unsubscribe send an email to users-leave@lists.genode.org Archived at https://lists.genode.org/mailman3/hyperkitty/list/users@lists.genode.org/mes...
Hi,
On Fri, May 08, 2026 at 20:48:15 CEST, Spencer via users wrote:
Is there a formal distinction between a blocking RPC and a non-blocking one, other than the expected time that will be taken?
That's the heart of it. A (remote) procedure call is synchronous and returns only after the called (remote) procedure decides to return. The differentiated consideration of "blocking" vs. "non-blocking" RPCs stems from our experience with services like the timer. Norman mentioned this and it's also documented in Foundations
https://genode.org/documentation/genode-foundations/25.05/architecture/Inter... https://genode.org/documentation/genode-foundations/25.05/architecture/Inter...
The underlying RPC mechanism is the same but the semantics of the service interfaces pledge limited blocking time.
Regards
-
Christian Helmuth -
Norman Feske -
Rumen Mitov -
Spencer