Is there a formal distinction between a blocking RPC and a non-blocking one, other than the expected time that will be taken?
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]
[2]
However, the out-of-order handling of RPCs is a can of worms, which is
nicely illustrated by [3].
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]
You may also find [5] worth reading to get a feel for the evolution of
Genode's current design.
[5]
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
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
_______________________________________________