sends don't block, right?
Thu Feb 26 07:53:42 CET 2004
On Wed, 25 Feb 2004 21:07:08 -0500, Shawn Pearce <spearce@REDACTED>
> Chris Pressey <cpressey@REDACTED> wrote:
>> btw, I agree 100% (maybe 1000%) with Joe on the idea that hiding IPC
>> stuff inside wrapper functions is just plain *wrongheaded*. Yes,
>> abstraction is good, but no, a function makes a *horrible* abstraction
>> for IPC -- especially in a "functional" language where functions aren't
>> supposed to have side-effects :)
> Yea, I've become convinced of this now too.
I agree. I'd like to be able to see message passing more clearly.
It will still be possible to hide it behind function calls, just
like today, since !! is only syntactic sugar.
One problem is that it's more difficult to trace IPC dependencies.
We have xref for finding function call dependencies between modules,
and at AXD 301, we have CCviewer which provides hypertext linking
with forward and backward references (basically, Emacs tags and Distel
do this too.) But what do you do to follow the trail of a message while
reading source code? It can be arbitrarily difficult. I've spent some
time pondering the problem trying to add something to CCviewer, but
it's not easy. And if you can't tell a tool where to jump, humans
will have more difficulty as well.
I'd like to see some invention here as well. This would strengthen Joe's
case that we could focus more on message passing and RPCs.
> So I'll just keep asking, when will !! become part of the langauge? :)
> I'd have to suggest that if !! is added the way Joe is suggesting
> (use a local rpc/2 function to do the send/receive operations) that the
> compiler either automatically generate an rpc/2 function if one is not
> supplied, or that it give a very good error message indicating that
> the rpc/2 function is missing, what it needs to do, and why the
> compiler is requesting it.
Or add an
Don't know if this should be done automatically - but probably.
gen:rpc/2 should use basically the same semantics as gen:call/2
(that would mean a default 5 second timeout), and there should
also be a gen:rpc/3, which one could easily use by adding
rpc(Server, Request) ->
gen:rpc(Server, Request, 17000).
e.g. for a 17 second timeout.
More information about the erlang-questions