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

[Alex Arnon]

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/20160828/b3a11fb1/attachment.htm>