[erlang-questions] prim_inet:ignorefd/2 affecting erts_poll_wait()

[Michael Truog]

On 08/24/2014 12:38 PM, Tony Rogvall wrote:
> I made a afunix version of the inet driver. You can find it here:
>
> https://github.com/tonyrog/afunix
>
> It will register it self as a socket so that afunix/gen_tcp/inet api is available.
>
> The reason I implemented it was the very same reason you had.
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.

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 http://erlang.org/pipermail/erlang-questions/2009-March/042180.html, 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 https://github.com/mikma/unixdom_drv/issues/3 .

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 (http://en.wikipedia.org/wiki/Named_pipe#In_Windows).

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)

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.

Thanks,
Michael
>
> /Tony
>
>
> On 23 aug 2014, at 03:01, Michael Truog <mjtruog@REDACTED <mailto:mjtruog@REDACTED>> wrote:
>
>> 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:
>> ...
>> {ok, FileDescriptorInternal} = prim_inet:getfd(Socket),
>> ok = prim_inet:ignorefd(Socket, true),
>> {ok, NewSocket} = gen_tcp:fdopen(FileDescriptorInternal, SocketOptions),
>> ...
>> 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).
>>
>> On 08/22/2014 05:46 PM, Michael Truog wrote:
>>> 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.
>>>
>>> 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?
>>>
>>> Thanks,
>>> Michael
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>> http://erlang.org/mailman/listinfo/erlang-questions
>
> "Installing applications can lead to corruption over time. 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"
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140824/1cd49d15/attachment.htm>