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