[erlang-questions] blocking vs non-blocking gen_tcp:accept()

Per Hedeland per@REDACTED
Mon Mar 3 01:08:47 CET 2008


Claes Wikstrom <klacke@REDACTED> wrote:
>
>Matthias Lang wrote:
>> Robin writes:
>>  > Does gen_tcp:accept() block the entire OS thread or just the calling
>>  > erlang process?
>> 
>> Just the erlang process. (verifying this yourself is straightforward)
>> 
>
>Having accept() as function that receives a message as opposed
>to hanging would make a lot of sense though.

One possibility might be to have gen_tcp:listen() actually obey the
{active, X} option with respect to the listen socket. I.e. the current
behaviour, which would remain the default, would correspond to {active,
false}, and you have to call accept() to get anything to happen. But if
you passed {active, once} or {active, true} you wouldn't call accept()
at all, but instead get a message e.g. {tcp_accept, ListenSocket,
AcceptSocket} when a connection was accepted. (And in the case of
{active, once} you'd then have to set the option again before another
accept can happen.)

One problem with that is that it isn't backwards-compatible though -
currently you can give {active, Whatever} to gen_tcp:listen() and it
doesn't affect the accept behaviour, but gets "inherited" by the
AcceptSocket. If someone uses that functionality for {active, once} or
{active, true}, they'd be in for a surprise - but maybe no-one does?:-)
({active, false} is probably common but wouldn't be a problem, and
{active, true} would seem pointless since it's the default for the
AcceptSocket anyway - which leaves {active, once} as the problem case.)

--Per Hedeland



More information about the erlang-questions mailing list