Open OTP-Maintainer opened 5 years ago
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.
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!
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.
raimo
said:
Naming and concepts are always hard, so thank you for those suggestions!
Original reporter:
okeuday
Affected version:OTP-21.0
Component:kernel
Migrated from: https://bugs.erlang.org/browse/ERL-732