[erlang-questions] How to solve the blocking accept call in a tcp_listener process ?
Wed May 20 02:36:44 CEST 2009
It depends on what you mean with "this", if it's gen_tcpd from the
repository you need to think about the following:
You'll need to think about what you do with the socket when
handle_connection is called, since this is a different process from the
one that is under the supervisor. At the time of handle_connection, the
process is linked to the gen_tpcd process (the one under the
supervisor). If this isn't what you want, you'll need to come up with
some other way of supervising the process handling the connection. My
general view on this is that you don't really need this directly under a
supervisor, since you would never want to restart it (the socket is dead
if you've crashed any way) but you do want it linked somewhere so that
you can kill it / keep track of it (for instance log crashes etc).
gen_tcpd also supports ssl, so there is a slight overhead (well, I can't
really see this making any real difference) when calling send, recv etc.
You'll also need to call gen_tpcd:send instead of gen_tcp:send...
If you're thinking about the approach in general:
Well, you need to keep track of the acceptor processes, either by
putting them under a supervisor (but this becomes as synchronization
point, which you probably don't want after concurrent accept), or just
link them to somewhere, which will log crashes.
Andrew Thompson wrote:
> On Wed, May 20, 2009 at 12:38:45AM +0100, Oscar Hellstr?m wrote:
>> An example of a generic accept loop (that can be used with OTP) can be
>> found here: http://code.hellstrom.st/hg.cgi/gen_tcpd/
>> You might not want to use this, but I got tired of rewriting the accept
>> loop every time... It was recently changed to have support acceptors as
> Any downside to replacing a gen_server using prim_inet with this? I
> don't need extreme performance, just a non-blocking tcp accept loop.
> erlang-questions mailing list
Office: +44 20 7655 0337
Mobile: +44 798 45 44 773
Erlang Training and Consulting Ltd
More information about the erlang-questions