[erlang-questions] gen_tcp nonblocking send

Daniel Ginsburg <>
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 mailing list