Re: RPC over channels

This is a tough and interesting issue. Let's put aside the whole RPC issue for a moment and look at how code progressed from C-land to Java-land. In C, the developer had to check return values from function calls to see if the function succeeded. That led to ignoring return values or testing with

Re: RPC over channels

> > > RPC over channels<http://groups.google.com/group/clojure/t/3fde5c39fb97054b> > > > > >toberepla...@gmail.com Aug 01 10:09AM -0700 > > With >ZeroMQ, it might be a router that delivers your request to the machine >it >thinks is

Re: RPC over channels

I'm uneducated here since I've not used Erlang in any real capacity. I thought that typically if A sent a message to B that caused B to raise an exception, that B would send an exception back to A and that A would error out. Thus, the client is blamed for the exception. Is this correct? In

Re: RPC over channels

On Erlang: sometimes you *want* to block on a node and wait for the answer of a remote node. It's implemented as message passing under the hood - the process gets de-scheduled, restarted in case of crash if you want et al. - but the semantics are clearly sequential and blocking. Erlang obviously al

Re: RPC over channels

RPC ties a local process (and all the memory its currently using) to a remote process. It glosses over the fact that that the link between these two processes is quite unreliable. In his thesis, Joe Armstrong also points that this system is not only susceptible to hardware/network failure, it's als

Re: RPC over channels

A client could use a timeout channel as its receive channel to get timeouts on a blocking call, though I don't think that's the right way to do it. Alternatively, implementing a blocking call with an optional timeout wouldn't be difficult, it just can't be the default. I think if you disallow

Re: RPC over channels

On Thu, Aug 1, 2013 at 1:09 PM, wrote: > There would be no intent to solve the messenger problem explicitly -- > those semantics are up to the user. By default, in the case of server > death, the client side will just no longer receive responses on its > receive-channel. In the case of a blocki

Re: RPC over channels

I'm thinking that a blocking call would be an ordinary call that subsequently continuously reads from the receive-channel and checks if the id matches, returns if it does, and puts the value back on the channel otherwise. In a blocking call, you are always locked to the performance of the serv

Re: RPC over channels

How would a blocking call be created? How would you implement this in a way that wouldn't lock one machine to another machine's performance. For quite some time now, RPC has been considered a very bad idea since it mixes reliable and unreliable semantics. With a network you're never actually sure

RPC over channels

With core.async, cljzmq , and now zmq-async , there's an opportunity to link RPC to channels and be free of the underlying transport system. I'm proposing an RPC library that sends and receives data over channels. The idea