[erlang-questions] can "gen_tcp:recv" blocks my entire server?

[Mazen Harake]

Have you looked into {active,once} ? I think it is more suitable in your 
case. My suggestion would be to open an accepted socket with {active, 
false}, then setopts(Sock,[{active, once}]) when you are ready to 
receive the request (in your code) and then handle that and go back to 
setopts(Sock,[{active,once}]) every time you want to get a packet in 
your code. It will be received as a message and is much easier to 
handler. recv is IMHO only used when you are very specific about the way 
the data should be read and to keep tighter flow control.

If you combine {active, once} with {packet, http} then you will have a 
much more stable ground to stand on, unless you want to hack-to-learn 
which I guess is good enough reason to do it any way you like :)

My 2 cents :)

GL,

/Mazen

On 22/04/2010 10:11, zabrane Mikael wrote:
> 2010/4/22 Paul Fisher<pfisher@REDACTED>
>
>    
>> Have you tried it?
>>
>>      
> Yes of course I have.
> This is why I'm asking if recv/2 is the problem in my server design?
>
>
>
>    
>> --
>> paul
>>
>> On Apr 21, 2010, at 6:16 PM, "zabrane Mikael"<zabrane3@REDACTED>
>> wrote:
>>
>>      
>>> Hi List,
>>>
>>> I'm impleting a simple Web server using gen_tcp:listen(Port, [...,
>>> {active,
>>> false}]) options.
>>> For each request, a child process is spawned to handle it.
>>> Then, each child process use gen_tcp:recv/2 to read data from the
>>> client
>>> socket.
>>> Very basic design!
>>>
>>> My question is simple. If one of my child processes calls
>>> gen_tcp:recv/2 and
>>> blocks (due to a slow client),
>>> does this also blocks all other spawned childs?
>>>
>>> If yes, what's the best way to read from a socket without blocking the
>>> entire server (i.e the other spawned processes)?
>>>
>>> Regards
>>> Zabrane
>>>        
>>      
>    

---------------------------------------------------

---------------------------------------------------

WE'VE CHANGED NAMES!

Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.

www.erlang-solutions.com