[erlang-questions] Mixing casts and calls

[Robert Raschke]

Hi David,

sounds a bit like you want to treat your C node as a resource, and that's a
perfect match for a gen_server.

I would simply hide all interaction with the C node *inside* the
gen_server. Your send/receive to the C node could therefore be handled
completely inside a gen_server call. You would still have the top level
function get_version(), but that would only do the gen_server:call, and the
handle_call then does the send to the C node and waits for the answer with
a receive.

Hoe that makes sense,
Robby



On 17 January 2014 09:17, David Welton <davidnwelton@REDACTED> wrote:

> Hi,
>
> I am working with a system that looks like this:
>
> C node <=======> Erlang <========> Java Node
>
> And we're looking at good ways to integrate everything.
>
> For instance, we want the Java node to be able to do a simple query
> that ends up getting some data from the C node, say, the version it's
> running or something like that.
>
> Since the Java code needs to be simple, we want to do the equivalent
> of rpc:call(hw_server, get_version, []) and wait for the answer. It
> shouldn't take long, and timeouts or whatever can be handled by Java
> in that case.
>
> However, to interact with the C node, the gen_server that manages it
> would want to do something like:
>
> {any, 'c@REDACTED'} ! get_version
>
> And then get the answer via handle_info.
>
> But if we're going to transform what is essentiall a 'call' -
> hw_server:get_version() - into a cast/response, somewhere there's got
> to be a receive.  For instance:
>
> get_version() ->
>    Ref = make_ref(),
>    gen_server:cast(hw_server, {get_version, Ref}),
>    receive
>       {Ref, version, Version} ->
>           Version
>     end
>
> This feels like I've left OTP behind though.
>
> We could put the receive in the handle_cast for the gen_server, but
> then that's going to block the whole thing on one call, which strikes
> me as a bad idea, although I guess it could also be used to protect
> the C node if it were unable to process more than one thing at once.
>
> Another approach would be to further work with our Java guy to have
> him send and receive the messages, but we were kind of hoping to hide
> some of the complexity from that part of the system.
>
> Thank you,
> --
> David N. Welton
>
> http://www.welton.it/davidw/
>
> http://www.dedasys.com/
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140117/4493cd1c/attachment.htm>