<div dir="ltr"><div dir="ltr">I've finally found the chance to look into this matter again.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 8 Oct 2020 at 09:46, Raimo Niskanen <<a href="mailto:raimo%2Berlang-questions@erlang.org">raimo+erlang-questions@erlang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Oct 03, 2020 at 03:00:10AM +0100, Guilherme Andrade wrote:<br>
> Hello list,<br>
> <br>
> Today I found a peculiar situation when using the new socket[1] module.<br>
> <br>
> Upon a `:send/3` call with `nowait` as the timeout returning `{select,<br>
> SelectInfo}`, the controlling process will sometimes receive a duplicate<br>
> reference within two asynchronous select messages; the second message comes<br>
> later /when/ the socket is closed by a separate process (not the<br>
> controlling one) just at the right time - the conditions are hard to<br>
> replicate.<br>
> <br>
> That is:<br>
> - the controlling process first gets a `{'$socket', socket(), select,<br>
> SelectRef}` message when the socket is available for writing<br>
> - the controlling process then gets a second `{'$socket', socket(), abort,<br>
> {SelectRef, closed}` message<br>
> ...and `SelectRef` is the same for both.<br>
> <br>
> I looked for the root cause within `prim_socket_nif.c` (OTP 22.3.4.10) and,<br>
> if I'm interpreting it correctly, this may happen upon 1) the socket<br>
> becoming available for writing and dispatching the message earlier passed<br>
> onto `enif_select_write`[2] and 2) a secondary process closing the socket<br>
> and dispatching the abort message while the controlling process is still<br>
> registered as a writer.<br>
> <br>
> However, the C NIF code responsible for handling `socket` stuff is quite a<br>
> lot to take in an afternoon, and I may have misunderstood it.<br>
> <br>
> Is my theory correct? Can select messages with a duplicate reference be<br>
> dispatched to the same process? And is this expected, or possibly a bug?<br>
<br>
It is not supposed to happen.  I'd call it a bug.  We will definitely<br>
look in to this.<br></blockquote><div><br></div><div>Here's an escript that quickly reproduces the issue on my machine (OTP 22.3.4.10, mac OS):<br><a href="https://gist.github.com/g-andrade/42ee10e5e1fc97c157ce0dc627cbf2b7">https://gist.github.com/g-andrade/42ee10e5e1fc97c157ce0dc627cbf2b7</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> I worked around it by flushing the controlling process message queue with<br>
> `receive` to avoid the unexpected, second message by generically consuming<br>
> any remaining `select` messages related to that socket.<br>
> <br>
> I can distill the code that replicates it (on OTP 22.3.4.10, mac OS) but<br>
> I'm asking about it first, just in case this is known or expected somehow.<br>
> The duplicate reference did caught me offhand.<br>
<br>
There has been lots of rewrites for instance regarding lock handling<br>
on the master branch, so it would be nice to know if this bug is<br>
still present on master.<br></blockquote><div><br></div><div>I ran the same script under OTP 23.1.1 and could not reproduce the issue, so it's very possibly been fixed somewhere along the way.</div><div><br></div><div>Should I create a ticket at <a href="http://bugs.erlang.org">bugs.erlang.org</a>?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
/ Raimo<br>
<br>
<br>
<br>
> <br>
> Cheers!<br>
> <br>
> [1]: <a href="https://erlang.org/doc/man/socket.html" rel="noreferrer" target="_blank">https://erlang.org/doc/man/socket.html</a><br>
> [2]: <a href="http://erlang.org/doc/man/erl_nif.html#enif_select_write" rel="noreferrer" target="_blank">http://erlang.org/doc/man/erl_nif.html#enif_select_write</a><br>
> <br>
> -- <br>
> Guilherme<br>
<br>
-- <br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Guilherme<br></div></div></div></div></div></div></div>