ambiguous services of children

[David Goltzsche]

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
>