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@...12...ceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main