[erlang-questions] Regarding Erlang gen_server's ability to handle requests concurrently

[Arshad Ansari]

Thanks a lot to all of you guys.. Your inputs were of tremendous help.

Regards,
Arshad

On Sun, Aug 28, 2016 at 8:47 PM Alex Arnon <alex.arnon@REDACTED> wrote:

> Hi Arshad,
>
> It is possible for a gen_server to asynchronously reply to a call() -
> return {noreply, NewState} and later use gen_server:reply(From, Reply).
> This enables handling of multiple calls using the single gen_server
> thread. Of course, you'll need to keep track of all delayed replies in your
> State etc. etc.
> Note that this has nothing to do with sockets :)
>
> Cheers,
> Alex.
>
>
> On Sun, Aug 28, 2016 at 1:00 AM, Felix Gallo <felixgallo@REDACTED> wrote:
>
>> Arshad --
>>
>> A single gen_server instance is single-threaded, handling only one
>> message at a time.  Gen_servers are not necessarily network related; they
>> have to work in conjunction with libraries like gen_udp and gen_tcp in
>> order to arrange to send and receive messages on networks.
>>
>> It's important to know that there are a few different kinds of socket:
>> "listen" sockets, which bind to a port on your computer's network interface
>> and wait for new connection attempts to get made, and "client" sockets,
>> which are sockets that can be communicated over once the connection has
>> been formed.  You can think of "client" sockets as having been peeled off a
>> "listen" socket.
>>
>> Listen sockets can be shared by sending them as part of a message to
>> another process, or by passing them as an argument to a process spawn
>> function.  In the case of tcp sockets, it's fairly natural to open a listen
>> socket, spawn child processes, passing them the listen socket, and for each
>> of the children to call accept(), which then returns to them a fresh new
>> unique client socket, in order to concurrently handle many simultaneous
>> connections.  A worked example is here, in the documentation:
>> http://erlang.org/doc/man/gen_tcp.html#Examples .
>>
>> Client sockets can also be shared and passed around, but since a client
>> socket can only be read by the client socket's owning process, this is of
>> limited utility.
>>
>> There are a large number of tunable parameters on your network card, in
>> your operating system, and in erlang that you can fiddle with to obtain
>> optimum performance if you're worried about erlang's scalability; the
>> documentation for gen_tcp is a good place to start.  Fred's excellent
>> 'Learn You Some Erlang' book also has a great chapter on all this:
>> http://learnyousomeerlang.com/buckets-of-sockets.
>>
>> F.
>>
>> On Sat, Aug 27, 2016 at 11:12 AM, Ehsan Mohammadi <ehsan.tck@REDACTED>
>> wrote:
>>
>>> i`m new to erlang but as far as i know you can`t share a socket in
>>> multiple process or threads
>>> so you can accept and get raw data in single server and do processing in
>>> a server pool or something like that
>>>
>>> On Sat, Aug 27, 2016 at 8:35 PM Arshad Ansari <arshadansari27@REDACTED>
>>> wrote:
>>>
>>>> Hello there,
>>>>
>>>> This is a generic question that I have regarding the ability of
>>>> gen_server to handle requests concurrently. Does gen_server create a
>>>> separate process per request (even when for each request coming from same
>>>> socket connection) or does it create separate process per socket
>>>> connection? If it is latter then there will be a single process responsible
>>>> for handling large number of messaging coming from single socket. In that
>>>> case, how to make sure that that single process can handle a very high load
>>>> coming from a single connection?
>>>>
>>>> I hope my question is clear!
>>>>
>>>> Regards,
>>>> Arshad
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>
>>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160829/39706428/attachment.htm>