gen_rpc_client:call and cast ..semantics and question
linearregression opened this issue · comments
-- gen_rpc_client semantics are different from rpc:cast
http://www.erlang.org/doc/man/rpc.html#cast-4
-- gen_rpc_client:cast. Is it necessary to use gen_server:call?
If you're referring to the return value, we can change that. The reason I use gen_server:call for cast too is to ensure that the call has been casted successfully on the other side. Semantically, this is different from rpc, but I never claimed full compatibility :)
Perhaps I should change it to cast, call and safe_cast which will use cast, call and call on the client gen_server. You should bear in mind this project is not 100% ready for mass consumption since it's missing a lot of the things that need to be implemented but I really appreciate the feedback!
I updated the develop branch with your ideas, check the 3 latest commits out
Hi, yea, I know it is a toy project at that moment from the git stats. Just bored.
Personally, since Erlang libraries are much less semantics consistent than other more widely used languages, I will pick and choose from Rpc. (e.g. gen_server:cast returns ok, rpc cast returns true.
PS: Personally, I prefer return ok which makes me think less given most are familiar with gen_server.
I agree, rpc:cast returning true seems incosistent but a lot of the lower-level OTP libraries use that convention (i.e. erlang:bump_reductions, erlang:exit and more). However, cast functions, both on gen_server and gen_fsm return ok. This is disturbing but I agree with your original proposal to make it as close to the orignal rpc module as possible (maybe even transparently replace it through parse transform at some point).
PS: It might seem like a toy project but I've been using this library in production for about 6 months with ~300k rpc calls/sec and ~60 nodes. RPC failed to scale at that scale so I had to create this.
Cool. If it happens my comments are coarse or anything. Please forgive me.
It is just my writing style very short, plain and dry like an old piece of bread if,not resort to, point form often time.
PS: it will be very interesting to see examples to show that the improvement on RPC in a separate repo. Better to pipe the log to tool to show some simple analytics as selling point.
For basic usage, while important, people can get by from the test script.
Don't worry about your writing style :) I'm gonna update the readme with the reasoning behind this project and performance tests in preparation for the SF Erlang meetup this Thursday (http://www.meetup.com/ErlangSF/events/225123831/)