<div dir="ltr"><div>Hello list,</div><div><br></div><div>Today I found a peculiar situation when using the new socket[1] module.</div><div><br></div><div>Upon a `:send/3` call with `nowait` as the timeout returning `{select, SelectInfo}`, the controlling process will sometimes receive a duplicate reference within two asynchronous select messages; the second message comes later /when/ the socket is closed by a separate process (not the controlling one) just at the right time - the conditions are hard to replicate.<br><br></div><div>That is:</div><div>- the controlling process first gets a `<span class="gmail-code">{'$socket', socket(), select, SelectRef}` message when the socket is available for writing</span></div><div><span class="gmail-code">- the controlling process then gets a second `<span class="gmail-code">{'$socket', socket(), abort, {SelectRef, closed}` message<br></span></span></div><div><span class="gmail-code"><span class="gmail-code">...and `SelectRef` is the same for both.</span></span></div><div><span class="gmail-code"><span class="gmail-code"><br></span></span></div><div><span class="gmail-code"><span class="gmail-code">I looked for the root cause within `prim_socket_nif.c` (OTP 22.3.4.10) and, if I'm interpreting it correctly, this may happen upon 1) the socket becoming available for writing and dispatching the message earlier passed onto `enif_select_write`[2] and 2) a secondary process closing the socket and dispatching the abort message while the controlling process is still registered as a writer.</span></span></div><div><span class="gmail-code"><span class="gmail-code"><br></span></span></div><div><span class="gmail-code"><span class="gmail-code">However, the C NIF code responsible for handling `socket` stuff is quite a lot to take in an afternoon, and I may have misunderstood it.</span></span></div><div><span class="gmail-code"><span class="gmail-code"><br></span></span></div><div><span class="gmail-code"><span class="gmail-code">Is my theory correct? Can select messages with a duplicate reference be dispatched to the same process? And is this expected, or possibly a bug?<br><br></span></span></div><div><span class="gmail-code"><span class="gmail-code">I worked around it by flushing the controlling process message queue with `receive` to avoid the unexpected, second message by generically consuming any remaining `select` messages related to that socket.<br></span></span></div><div><span class="gmail-code"><span class="gmail-code"><br></span></span></div><div><span class="gmail-code"><span class="gmail-code">I can distill the code that replicates it (on OTP 22.3.4.10, mac OS) but I'm asking about it first, just in case this is known or expected somehow. The duplicate reference did caught me offhand.<br></span></span></div><div><span class="gmail-code"><span class="gmail-code"><br></span></span></div><div><span class="gmail-code"><span class="gmail-code">Cheers!<br></span></span></div><div><br></div><div>[1]: <a href="https://erlang.org/doc/man/socket.html">https://erlang.org/doc/man/socket.html</a><br>[2]: <a href="http://erlang.org/doc/man/erl_nif.html#enif_select_write">http://erlang.org/doc/man/erl_nif.html#enif_select_write</a></div><div><div><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Guilherme<br></div></div></div></div></div></div></div></div></div>