RPC with LWIP

[Mhamad Hmad]

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



-- 
*Mohammad Hamad*

IDA, Institute of Computer and Network Engineering
Technical University of Braunschweig
Hans-Sommer-Str. 66
38106 Braunschweig - Germany
Mobile: (+49) 179 1613941
Email: mhh.it1986 at ...9...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20140625/1ed86aab/attachment.html>