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@lists.sourceforge.net From: norman.feske@...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:
The argument is copied into the message to be sent to the server.
The server instantiates a temporary object of the argument type and copies the argument from the message to the temporary object.
The server-side RPC method is called with a reference to the temporary object as argument.
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main