sends don't block, right?

[Francesco Cesarini]

There are design rules 
(http://www.erlang.se/doc/programming_rules.shtml) to always flush 
unknown messages, logging the error. I usually go a step further and 
suggest people make their gen_server code crash through a badmatch if 
they receive unknown calls and casts, as they are bugs and should not be 
sent. For handle info, always add a debug printout, as the story is 
slightly different. Messages for ports closing, nodes going down, 
possibly expired time-outs, or as I recently discovered, results from 
asynchronous RPCs, and other junk might appear.

Shawn - If you are worried about a blocking parent, you could solve your 
problem with asynchronous call-backs and time-outs.

Cheers,
Francesco
--
http://www.erlang-consulting.com

Shawn Pearce wrote:

>Ok, colo(u)r me stupid now (borrowed phrase, sorry!):
>
>! doesn't block, right?
>
>If I do something foolish like this:
>
>	never_end() ->
>		Pid = spawn(fun() -> receive foo -> ok end),
>		do_loop(Pid).
>
>	do_loop(Pid) ->
>		Pid ! bar,
>		io:format("still going, just like the bunny~n", []),
>		do_loop(Pid).
>
>will the parent ever stop because the child's message buffer is full?
>
>Basically, I'm asking if Erlang will let the parent in this case run
>the VM out of memory before making the parent freeze.  Clearly one should
>never write this code, but I'm trying to setup an async-send for my
>serial driver that will "never" block the caller, as apposed to the
>blocking send which makes sure the data was delivered to the endpoint
>before returning.
>
>The only reason I'm concerned here is the caller could lock up if it
>gets blocked and hardware or software flow control breaks down due to
>link failure.
>
>With most serial protocols I wouldn't see the need to buffer more than
>a few hundred KB of data, and the port driver already has buffers deep
>enough to handle that, so in theory, port_command/2 should never block.
>I just want to keep from blocking up the application, if the application
>so desires.
>
>  
>