sends don't block, right?

[Shawn Pearce]

Chris Pressey <cpressey@REDACTED> wrote:
> I'd much, much, MUCH rather it just kill the receiving process or
> (better) discard the message after a receive buffer limit is reached,
> than taking down the entire node, though.

I agree.  If the node cannot give memory to a process for its heap or
its message queue, the process should be immediately killed with the
reason 'enomem'.  This kill should not be trappable by any catch
expressions either.

If the developer/designer/whatever doesn't want the process to just
vanish in low memory conditions they should setup a proper supervision
tree.  A good supervisor won't allocate memory, and thus should be able
to have enough free temporary space to get the 'EXIT' message of the
child, realize its an enomem error, and handle it somehow.  It may just
be enough to restart the process as the process may have just been
leaking a ton of memory (by stuffing things into its dictionary for
example).

> Used it more in terms of sheer hours, perhaps; know it better, probably
> not -- I'm still essentially mystified by OTP and erl_interface...

Heh.  I don't think there's many out there who really do know OTP.  One
thing I pick up well is low-level guts of almost anything.. so I feel
like I have a decent grasp on how much of OTP works, but certainly cannot
claim to know it as well as many of the folks here.  erl_interface isn't
bad either.. pretty simple actually.  Which is a pleasure compared to
some of the other higher-level languages and their interfaces.

> 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.

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.

-- 
Shawn.