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 also very susceptible to programming failures. A bug in your code could cause every 100th RPC call to fail, for example.
So instead of all of this, Erlang (or actually Erlang's OTP libraries) proposes a different view: 1) all messages are sent async and unreliable. This is the way networks are designed anyways, if you sent a message to a remote system and it gets thrown into a queue, you really don't know what happens to that message in the end, except by asking the remote system again, and again until you finally get an ACK. 2) If we follow the above model, then we can start programming in a fail-fast mode. This is what OTP is based on. Supervisor processes that reset dead sub processes. This is also why I'm not a fan of populating error messages across channels. Instead, errors should kill go blocks, and then those blocks should be restarted by supervisors. So RPC assumes that every call will succeed. Message passing systems assume that it's kind-of-sort-of-not-really-likely that your message will arrive at the remote system. It's a pessimistic view of the world. And with the systems I work with, this is the best approach. So I guess this is a super long way of saying I love the OTP style and would love to see it ported to core.async. But RPC is not the way, blocking send/recv is not the way. To get reliable systems you need your system to always be capable of forward progress, and having a local process tightly coupled to a remote process will not get you there. Timothy On Thu, Aug 1, 2013 at 1:55 PM, ToBeReplaced <toberepla...@gmail.com> wrote: > 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 disallowed nil as a response, then it would be easy to use > a variety of different blocking calls -- wait forever, wait 30 seconds, > wait until (f) returns truthy, etc. > > -ToBeReplaced > > > On 08/01/2013 03:36 PM, Cedric Greevey wrote: > > On Thu, Aug 1, 2013 at 1:09 PM, <toberepla...@gmail.com> 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 blocking call, this means that the >> client side will hang. >> > > Ugh. At the *very* least it should eventually return with some kind of a > timeout exception. > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/P95cOfuXBUs/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
