sends don't block, right?
Wed Feb 25 08:53:52 CET 2004
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.
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) ->
> Pid ! bar,
> io:format("still going, just like the bunny~n", ),
>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
>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
>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
More information about the erlang-questions