RPC parameters

[Bilal ma]

Thank you Norman, it is really more than sufficient answer. since i am still new with Geonde it may early to give an advise, regarding to the book ,it is an amazing effort  ( i went through few parts of it since yesterday),  but do you think that it will be better to include some more code examples. what i mean is making the book as reference to "how to develop in Genode".  
thank you again for your answering. best. 
> Subject: Re: RPC parameters
> To: genode-main at lists.sourceforge.net
> From: norman.feske at ...1...
> Date: Thu, 14 Jan 2016 12:09:30 +0100
> 
> Hello,
> 
> On 14.01.2016 11:52, Bilal ma wrote:
> > Thank you for the examples, does it make difference if i  don't pass my
> > input-output POD struct by reference  since it need to be copied to the
> > server side, and later from the server to the client. 
> > from the point view of  performance  which one is the best if we add the
> > option of placing my POD in shared memory. 
> 
> the RPC mechanism always copies data. It does not use shared memory.
> Please review Section 8.12.2. "Transferable argument types" to get a
> picture how different argument types are handled.
> 
> If a reference is passed as argument, the following steps are taken:
> 
> 1. The argument is copied into the message to be sent to the server.
> 
> 2. The server instantiates a temporary object of the argument type
>    and copies the argument from the message to the temporary object.
> 
> 3. The server-side RPC method is called with a reference to the
>    temporary object as argument.
> 
> 4. Once the server-side RPC method returns, the new content of the
>    temporary object is copied to the reply message buffer.
> 
> By using the temporary object instance, it looks like you pass a
> reference. But under the hood, the server operates on a different object.
> 
> You mentioned performance. If you need to transfer large amounts of bulk
> data between components, you may consider shared memory. For a
> description of how to set up shared memory between components, please
> refer to Section 3.6.3. "Shared memory" in [1].
> 
> That said, I recommend you to think twice about introducing a new
> session interface. Maybe an existing interface would do the job just
> fine when looking at your problem from a slightly different angle? To
> cite the intro of Chapter 4:
> 
>  "The versatility of a component-based system does not come from
>   the existence of many components alone.  Even more important is
>   the composability of components. Components can be combined only
>   if their interfaces match. To maximize composability, the number
>   of interfaces throughout the system should be as low as possible,
>   and all interfaces should be largely orthogonal to each other."
> 
> Whereas it is a nice exercise to design a custom RPC interface, I mostly
> advise against it. In particular, if your interface is just a bunch of
> getters and setters, the existing ROM and Report session interfaces may
> accommodate you quite well.
> 
> [1] http://genode.org/documentation/genode-foundations-15-05.pdf
> 
> Cheers
> Norman
> 
> -- 
> Dr.-Ing. Norman Feske
> Genode Labs
> 
> http://www.genode-labs.com · http://genode.org
> 
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
> 
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20160114/865751b8/attachment.html>