<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/24/2014 12:38 PM, Tony Rogvall
wrote:<br>
</div>
<blockquote
cite="mid:C7DF93BC-6938-4CA8-BC61-08E8A73B03A2@rogvall.se"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
I made a afunix version of the inet driver. You can find it here:
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://github.com/tonyrog/afunix">https://github.com/tonyrog/afunix</a></div>
<div><br>
</div>
<div>It will register it self as a socket so that
afunix/gen_tcp/inet api is available.</div>
<div><br>
</div>
<div>The reason I implemented it was the very same reason you had.</div>
</blockquote>
Thank you for mentioning afunix. This is actually doing unix domain
socket support the right way. However, that also is a bit scary
because it requires replicating so much source code from the inet C
source code. It doesn't seem like there is any easier way though,
to do it properly. I know the dup2 trick I am doing is dirty, but I
was hoping to avoid creating any C source code to make it work. As
it is right now, I was forced to handle the accept in a NIF, so I
still need some C source code for the dup2 trick, but it still is
small.<br>
<br>
I guess the only thing better than afunix will be to have unix
domain socket support in Erlang/OTP. I really don't understand why
it isn't a priority, due to it being a constant concern for over 5
years. I know there is an old email thread about the issue in 2009
<a class="moz-txt-link-freetext" href="http://erlang.org/pipermail/erlang-questions/2009-March/042180.html">http://erlang.org/pipermail/erlang-questions/2009-March/042180.html</a>,
but I know the problem goes back further than that along with the
creation of unixdom_drv which is part of jungerl. I know
unixdom_drv was broken due to new validation that was added to inets
as mentioned here <a class="moz-txt-link-freetext" href="https://github.com/mikma/unixdom_drv/issues/3">https://github.com/mikma/unixdom_drv/issues/3</a> .<br>
<br>
If anyone doesn't understand this situation, this doesn't have
anything to do with UDP support and this is unrelated to the
uds_dist example (which shows a way of using distributed Erlang with
unix domain sockets). Named pipes would be the equivalent to unix
domain sockets on Windows, despite the differences
(<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Named_pipe#In_Windows">http://en.wikipedia.org/wiki/Named_pipe#In_Windows</a>).<br>
<br>
Is the reason that unix domain sockets don't get support the
unix-only association they have? (i.e., no clear Windows equivalent,
better than named pipes)<br>
<br>
I will have to think about using afunix a little more. It is
probably the lesser of two evils, but it still seems like a concern.
afunix should be the best way to currently approach the unix domain
socket problem. However, the afunix source code will be difficult
to maintain as the Erlang/OTP inet source code receives fixes. I
know the Erlang/OTP source code doesn't change a ton, but it still
seems like a concern, if not maintenance then purely due to
complexity and SLOC/size (which are all connected). Thank you for
releasing afunix as open source. If unix domain sockets were
eventually implemented in Erlang/OTP, afunix would provide a way of
transitioning to that support in a straightforward way.<br>
<br>
Thanks,<br>
Michael<br>
<blockquote
cite="mid:C7DF93BC-6938-4CA8-BC61-08E8A73B03A2@rogvall.se"
type="cite">
<div><br>
</div>
<div>/Tony</div>
<div><br>
<div><br>
<div>
<div>On 23 aug 2014, at 03:01, Michael Truog <<a
moz-do-not-send="true" href="mailto:mjtruog@gmail.com">mjtruog@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">To be a little clearer, my
prim_inet:ignorefd/2 usage is to use a file descriptor
created in the inet source code after passing it through
gen_tcp:fdopen/2. So, the sequence is:<br>
...<br>
{ok, FileDescriptorInternal} = prim_inet:getfd(Socket),<br>
ok = prim_inet:ignorefd(Socket, true),<br>
{ok, NewSocket} = gen_tcp:fdopen(FileDescriptorInternal,
SocketOptions),<br>
...<br>
While this might seem odd, this allows me to dup2 the file
descriptor without causing obvious problems and handle
UNIX domain sockets, which are currently unsupported
within inet (by avoiding the internal checking that
prevents their use).<br>
<br>
On 08/22/2014 05:46 PM, Michael Truog wrote:<br>
<blockquote type="cite">I have been seeing the
erts_poll_wait() thread consume 100% CPU when my
configuration makes prim_inet:ignorefd/2 ignore a fd
(inet_descriptor has is_ignored set to true) created
external to inet (10 file descriptors created this way).
I don't have this problem when using the inet code to
create tcp sockets, when prim_inet:ignorefd/2 is not
used with the same configuration. When setting "#define
INET_DRV_DEBUG 1" in
"./erts/emulator/drivers/common/inet_drv.c" and "#define
ERTS_POLL_DEBUG_PRINT" in
"./erts/emulator/sys/common/erl_poll.c" all the
debugging output looks the same when exercising the file
descriptors in the same way. The only difference seems
to be the "Entering erts_poll_wait(), timeout=NUMBER"
output has non-zero timeout values more often when
prim_inet:ignorefd/2 is not used when compare to the
output when it is being used. Also, the NUMBER doesn't
seem to go about 1000 for me when prim_inet:ignorefd/2
is used, but it can go above 1000 when
prim_inet:ignorefd/2 is not used.<br>
<br>
Why would the erts_poll_wait() loop be refusing to
timeout? Is this expected behaviour? Is there an erts
configuration flag which is meant to address the
problem?<br>
<br>
Thanks,<br>
Michael<br>
</blockquote>
<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a moz-do-not-send="true"
href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a class="moz-txt-link-freetext" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote>
</div>
<br>
<div>
<span class="Apple-style-span" style="border-collapse:
separate; border-spacing: 0px;">
<div><span class="Apple-style-span" style="color: rgb(51,
51, 51); font-family: Geneva, Arial, Helvetica,
sans-serif; font-size: 12px; ">"Installing
applications can lead to corruption over time. </span><span
class="Apple-style-span" style="color: rgb(51, 51,
51); font-family: Geneva, Arial, Helvetica,
sans-serif; font-size: 12px; ">Applications gradually
write over each other's libraries, partial upgrades
occur, user and system errors happen, and minute
changes may be unnoticeable and difficult to fix"</span></div>
<div><span class="Apple-style-span" style="color: rgb(51,
51, 51); font-family: Geneva, Arial, Helvetica,
sans-serif; font-size: 12px; "><br>
</span></div>
</span><br class="Apple-interchange-newline">
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>