[erlang-questions] A possible problem with the canonical listener idiom

[Serge Aleynikov]

John Haugeland wrote:
> 
>     at the end it clearly states that the use of {active, true} is not
>     advised for high traffic conditions as it doesn't have flow control.  
> 
> 
> This isn't about flow control.  This is about losing initial packets 
> because they're going to the wrong process.

The Erlang network driver presents another logical middleman "actor" in 
communication between TCP client and an Erlang TCP server process. 
Since TCP has built-in flow control and recovery from packet loss, the 
flow control and race conditions we are talking about are not so much 
between TCP client and a TCP server processes, but is between the 
network driver and the process receiving messages coming from a TCP 
client through the driver.  Proper synchronization of that message 
delivery is the flow control that can guarantee that messages make it to 
correct mailboxes.  {active, false} says to the driver: "Hey, don't read 
anything from that socket until the socket's owner instructs you to do 
so, or someone reads the message explicitly".  If you prefer not to call 
this "flow control" you can come up with a more pleasing name for it.

>  {active,once} is immune to 
> the flow control problem, and if you write a server capable of managing 
> its own flow control, the initial packets are still at risk of being 
> lost.  Indeed, the code you linked to suffers the defect I'm discussing, 
> and can lose packets for the same reason that the prior example can.

Could you kindly point me to the place in code in that tutorial at 
trapexit where you see the race condition?  The process owning the 
listening socket has it open with {active, false}.  After accepting a 
client's socket that socket *inherits socket options* (including 
{active, false}) from the listener, and transfers ownership of the 
socket to the newly spawned client handling process by calling 
Module:set_socket/2, which does inet:setopts(Socket, [{active, once}]) 
in the context of the process different from the listener.

I don't see a race condition here.

Serge