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 also has benefits in that area with OTP supervision and the lightweight processes - but doesn't core.async have at least the last one too?
Take a look into Basho's riak_core (https://github.com/basho/riak_core) and other distributed systems written in Erlang: heavy use of RPC calls. So I'd say on RPC: clearly depends on your needs and is not automatically bad. Marc On 2 August 2013 15:46, Timothy Baldridge <tbaldri...@gmail.com> wrote: > 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. > > > -- -- 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.
