[erlang-questions] can "gen_tcp:recv" blocks my entire server?
zabrane Mikael
zabrane3@REDACTED
Thu Apr 22 14:23:21 CEST 2010
I'll try the {active,once} advice.
Thanks!
2010/4/22 Mazen Harake <mazen.harake@REDACTED>
> 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
>
>
More information about the erlang-questions
mailing list