<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 9:59 PM, Michael Truog <span dir="ltr"><<a href="mailto:mjtruog@gmail.com" target="_blank">mjtruog@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 01/28/2015 07:19 PM, Matthieu Tourne
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">Hi,
        <div><br>
        </div>
        <div>I started using py_interface as a layer to do rpc into an
          Erlang system, receive and send message, and eventually
          provide functionality to the that Erlang system.</div>
        <div><br>
        </div>
        <div>One of the functions on the Erlang side would be :</div>
        <div><br>
        </div>
        <div>handle_call({subscribe, Channel}, From, State) -></div>
        <div>  %% Saves From as a subscriber of this channel into the
          State</div>
        <div>  %% When something will arrive on the Channel From will
          get a message.</div>
        <div><br>
        </div>
        <div>The problem is when I'm sending an rpc:call via
          py_interface (a call message on the rex mailbox essentially).
          It seems that the pid associated to that rpc essentially
          disappears right when the rpc is completed.</div>
        <div><br>
        </div>
        <div>As I gathered from this example [1], an alternative way to
          do this would be to rewrite my handle_call this way : </div>
        <div><br>
        </div>
        <div>handle_call({subscribe, Channel, SubscribingPid}, _From,
          State)  -><br>
        </div>
        <div>  %% Saves SubscribingPid instead of From.</div>
        <div><br>
        </div>
        <div>And I would pass in the Pid of an active mailbox from my
          py_interface hidden node.</div>
        <div><br>
        </div>
        <div>My question is two fold, would there be a way to keep a
          live Pid in the system (maybe [2] answers this problem as a
          byproduct), for longer than getting a result to that rpc call.</div>
        <div>Or would a proper way to do this be to have a proxy process
          to make the link between rpc's and a live mailbox in my hidden
          node.</div>
        <div>Also, is a hidden node the best way of achieving all of
          this ?</div>
      </div>
    </blockquote></span>
    py_interface makes the running Python interpreter into a hidden
    node, similar to a cnode
    (<a href="http://www.erlang.org/doc/tutorial/cnode.html" target="_blank">http://www.erlang.org/doc/tutorial/cnode.html</a>), just using Python
    source code (like jinterface does with Java source code).  You could
    probably modify the py_interface source code to run as an Erlang
    port (<a href="http://www.erlang.org/doc/tutorial/c_port.html" target="_blank">http://www.erlang.org/doc/tutorial/c_port.html</a>).  In both
    cases, all Python usage will have a single connection bottleneck (a
    single socket for a cnode and a single pair of pipes for a port). 
    Depending on the Python source code, you could argue that it will
    never matter due to the global interpreter lock.<br>
    <br>
    However, if you do care about Python latency, it is more efficient
    to use the Python CloudI API.  To do RPC you would send a service
    request to another CloudI service (based on your example, an Erlang
    CloudI service).  An example of a Python service is at
    <a href="http://cloudi.org/#Python" target="_blank">http://cloudi.org/#Python</a> to show how a service request can be
    handled in Python (adding a send_sync CloudI API function call
    (<a href="http://cloudi.org/api.html#1_send_sync" target="_blank">http://cloudi.org/api.html#1_send_sync</a>) would be the same as doing
    RPC).  The Python CloudI API is implemented only in Python in the
    cloudi module and with Python/C integration in the cloudi_c module
    (the quickest Python integration).<span class=""><br>
    <br></span></div></blockquote><div><br></div><div>I was actually looking at CloudI just yesterday! </div><div>It looks very interesting, and seems to work like magic in my use case [1] :)</div><div><br></div><div>I would have couple questions about it, what powers the api system ? </div><div>Reading the code briefly I saw some Erlang external term format, but it wasn't clear which channel the protocol used (socket, pipes, etc ).</div><div><br></div><div>Also I was wondering if everything would need to become a cloudi_service to be consumed seamlessly by an external API, I'm working with existing code that already has a lot of gen_server patterns, if I have to layer on top this could be a burden.</div><div><br></div><div>Finally not running on windows could be a problem, but I'm guessing I could rip out just CloudI API part of CloudI (it's a big repo) and make sure that works.</div><div><br></div></div>[1] <a href="https://github.com/CloudI/CloudI/tree/develop/doc#python">https://github.com/CloudI/CloudI/tree/develop/doc#python</a></div></div>