Hi Norman,
thank you for your replay, Acctually i am thinking in using the second option by making the server multi-threaded (using one entrypoint per session). but in this case i am facing the problem that the RPC has its own schedule and the LwIP also has it is own one too . So in one case i will have that the RPC waiting in one point and the LWIP waiting in different place so isthere any way to try to combine the both wait points in one .
2014-06-15 19:33 GMT+01:00 Norman Feske <norman.feske@...1...>:
Hi,
*I am little confused . Do i need to change all the liwp socket calls wich has blocking property like (accept , recvfrom,etc ) with non blocking calls, then I need to use asynchronous notifications. instead of using Block RPC calls , *
you would still use RPC calls for the those operations but they won't block on the server side. Let me illustrate the idea with a simple example using a 'read' function provided by a terminal-like server. The client wants to wait for user input by calling 'read'. From the client's perspective, the call of 'read' should block until new user input is available. When returning, the function should return the new user input.
With your original design, the client called the server's 'read' RPC function. If the server had no input, it would block. While blocking, however, no other client could be served.
My proposal to overcome this situation combines RPC calls with asynchronous notifications: We add a new function to the RPC interface that allows the client to register a signal handler. The function takes a 'Signal_context_capability' as argument. This signal context capability is created by the client using the signal API (see 'base/signal.h', and the 'Signal_receiver::manage()' function in particular).
After creating a session, the first thing the client does is to install the signal handler. Then, it uses the server by calling 'read'. If the server has input available, it will return the data right away. Both server and client are happy. If the server has no input available, the server would respond with a return code that tells the client that it's now time to block. E.g., for the read function, the server could just return a 0. If the client detects this condition, it would block using 'Signal_receiver::wait_for_signal()'. The server, however, is not blocking and can server other clients.
Now, if new input arrives at the server, the server would buffer the data and submit a signal to the signal handler that was registered by the client (using 'Signal_transmitter::submit()'). This signal will unblock the 'wait_for_signal' function at the client. Now, the client will again call 'read' to receive the new data.
Throughout Genode, you can find several examples that employ this scheme. I already mentioned the timer-session interface. But you may also have a look at the terminal-session.
Best regards 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
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main