ERL-732: Permanent support of prim_inet:async_accept functionality

[OTP-Maintainer]

Original reporter: okeuday
Affected version: OTP-21.0
Component: kernel
Migrated from: https://bugs.erlang.org/browse/ERL-732

---

This is a request that functionality similar to {{prim_inet:async_accept}} might be provided within the rewrite of the inet source code as a NIF, to ensure the functionality becomes supported and documented.  Doing this would help provide simpler socket use that is natural within an Erlang process.

This issue is similar to https://bugs.erlang.org/browse/ERL-646 though it is specific to the rewrite of the inet source code as a NIF and it isn't focused on providing the same name or source code path.

[OTP-Maintainer]

essen said:

Perhaps the older ticket is not explaining things the best, but we opened it because there was a risk the prim_inet:async_accept functionality would be cut off from the NIF rewrite, and we want to use this functionality in Ranch 2.0 onward. The older ticket also says it could be added to gen_tcp for example. So I think this is a duplicate.

[OTP-Maintainer]

raimo said:

The NIF rewrite will introduce lower level socket APIs in new module(s) that are a closer mapping to the Unix socket API.  The Unix socket API allows asynchronous accept through poll()/select() and non-blocking accept().  The NIF layer has got a similar structure but instead of returning from select() ({{enif_select()}}) sends a notification message.

The question is if we can expose this in a nice way. We will have it in mind!

[OTP-Maintainer]

okeuday said:

[~raimo] Ok, I am asking because it has been advantageous in the past to rely on the accept as an Erlang message to the Erlang process that owns the listening socket and I know that doesn't necessarily have a good equivalent within BSD sockets.  The idea of relying on an Erlang message (matching a function clause in a behaviour is pure while the receive is impure) instead of an impure function call for socket use has been the difference between {{active}} and {{passive}} in the past.  Utilizing active/passive names in the new API to distinguish between the different effects may be helpful (in options and/or function names) for both performance and limiting side-effects.

[OTP-Maintainer]

raimo said:

Naming and concepts are always hard, so thank you for those suggestions!