Hi Norman,
thanks for the detailed answer. I considered your hint regarding the trustworthiness of the clients: now the parent is providing the service to its children.works like a charm! the slave approach also worked, but i think the reversed way is more elegant. i should have thought of that earlier ;)
in the next step, the parent shall process the calls from its client. thus, its necessary that the parent knows the label of the child which issued the call. The child sets its label in Child_policy::filter_session_args(...). my question is: how does the parent obtain these session arguments ?
maybe there is another ( better? ) way to obtain the childs name?
thanks for your support! David
On Mi, 2014-09-24 at 14:31 +0200, Norman Feske wrote:
Hi David,
thank you for giving a bit more background about your work.
According to your description, the parent process spawns several services as its children and wants to invoke any of those services in any order. To accommodate this pattern (a parent uses a child as a service), we introduced the so-called 'Slave' utility. To illustrate how to realize a scenario like your's using this API, I have put together the following example:
https://github.com/nfeske/genode/commits/slave_example
The example consists of two parts. The 'test-slave_master' is the parent process, the 'test-slave_child' is the child that provides a "LOG" service. In the example, the parent starts two instances of the child service and subsequently invokes each of them. Hopefully, the example guides you to the right direction. If you have questions about the code, please don't hesitate to ask.
That said, let me point out a potential risk of this design. By having the parent use its own children as services, the parent has to inherently trust those children to respond to the RPC calls. In the example, the parent calls the 'write' function at the child. If the write function had bug (e.g., it keeps stuck in an infinite loop), the parent would wait infinitely for the response of the function. Consequently, the parent must trust the child in this respect.
If this is a problem for your scenario, I recommend to turn the client-server relationship upside-down: Implement a service in the parent where each child can pick up messages. So the each child calls the parent but not vice versa.
Cheers Norman