[erlang-questions] gen_tcp nonblocking send
Thu May 1 21:16:58 CEST 2008
Valentin Micic wrote:
> Under normal circumstances (as you've outlined), if sender and
> receiver are not in some kind of "synchronous" engagement, in other
> words, if your next send does not depend on receiving something from a
> remote peer; and you have a "sluggish" remote receiver, your process
> would block once local buffer is full.
> If you change this by introducing intermediate server, as suggested
> -- call it a REALY; you are not changing the fact that this RELAY
> will block when local sending buffer gets full.
> However, as the sending process is now sending "normal" Erlang
> messages, it will have no way of figuring out that RELAY's buffer is
> full, thus, it will keep sending, eventually clogging RELAY's process
> message queue.
The trick is to introduce "some kind of synchronous engagement" you
referred earlier between the sending process and the relay. Thus you can
avoid filling up the relay's queue. If you will, relay is a "converter"
between two modes of operation: non-pipelined-request-reply between
relay and sender, and
pipelined-but-possibly-blocking-on-send-buffer-filling-up between relay
and remote receiver.
> In my experience, once process has a few hundred thousands of such
> messages in its queue, Erlang scheduling starts having problems
> (actually, this is largely due to the CPU utilization, but there is a
> relationship), hence you are degrading performance of other processes
> as well.
True, but avoidable.
More information about the erlang-questions