[erlang-questions] Re: Unicast 20k messages, $500-$1000 bounty

[Joel Reymont]

On Jul 17, 2009, at 10:03 AM, Paulo Sérgio Almeida wrote:

> I have a feeling async threads are for File I/O, but even if they  
> are used for TCP, the problem still holds. They would tolerate a  
> transient slowness. But if some client(s) are persistently slow and  
> cannot keep up, after the TCP window has been exausted and all async  
> threads have also been exausted, then it will block.


Do you have any code that simulates this scenario?

This is what prim_inet:send looks like:

%% This is a generic "port_command" interface used by TCP, UDP, SCTP,  
depending
%% on the driver it is mapped to, and the "Data". It actually sends  
out data,--
%% NOT delegating this task to any back-end.  For SCTP, this function  
MUST NOT
%% be called directly -- use "sendmsg" instead:
%%
send(S, Data) when is_port(S) ->
     ?DBG_FORMAT("prim_inet:send(~p, ~p)~n", [S,Data]),
     try erlang:port_command(S, Data) of
         true ->
             receive
                 {inet_reply,S,Status} ->
                     ?DBG_FORMAT("prim_inet:send() -> ~p~n", [Status]),
                     Status
             end
     catch
         error:_Error ->
             ?DBG_FORMAT("prim_inet:send() -> {error,einval}~n", []),
              {error,einval}
     end.

It looks like it will block waiting for a port reply.

Since the result of gen_tcp:send is ignored in the broadcasting loop,  
perhaps erlang:port_command can be used directly on the socket to make  
things completely asynchronous and avoid the need for a middleman  
process.

I think solid proof is needed here rather than speciluation.

---
Mac hacker with a performance bent
http://www.linkedin.com/in/joelreymont