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

Lukas Larsson garazdawi@REDACTED
Tue Aug 26 09:29:25 CEST 2014


On Sat, Aug 23, 2014 at 2:46 AM, Michael Truog <mjtruog@REDACTED> 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.

If you could add "#define DEBUG 1" at the start of the inet_driver a bunch
of asserts should be enabled that might catch this error. What I suspect is
happening is that for some reason the fd that was supposed to be ignored
has been put into the pollset when it shouldn't have been which could
trigger quite bad behaviour. How that has happened I don't know though.

> 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?

I would imagine this is because there is a fd in the pollset that triggers
immediately. The thread that does the polling first spins a couple of times
over poll with 0 timeout to see if it can get some triggered fd's before it
goes to sleep waiting for events. If it does find a triggered fd the spin
count is reset and it starts spinning again.

> Thanks,
> Michael
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140826/8e059a8d/attachment.htm>

More information about the erlang-questions mailing list