Poll::poll(): Retry select() on EINTR

[asayers]

Usually the user should retry poll() on EINTR; however, this is an
easily-overlooked case. Let's improve the reliability of mio-based
programs by handing EINTR by default.

Closes #494.

[carllerche]

Thanks. I believe that the timeout would need to be updated before poll is attempted again?

[asayers]

Sorry for the slow response. Yes, you're right.

[carllerche]

A CI fix has been merged to master. Would you mind rebasing when you have a moment? Thanks!

[asayers]

Rebased. The iOS CI run timed out after starting the test program. I can't tell if this failure is genuine - is it possible to rerun the test?

[carllerche]

It probably is spurious. iOS CI is really janky.

[asayers]

Added a line to the changelog.

[carllerche]

At this point, would you not break? While probably an implausible situation, if each call to select returns w/ an interrupt, this would cause an infinite loop?

[asayers]

I assumed that calling select with a timeout of 0 is non-blocking and therefore can't return EINTR, but to my surprise a bit of googling revealed that "non-blocking syscalls don't return EINTR" is not actually documented behaviour. I'll change to a break.

EDIT: I found an email from David Miller saying that EINTR is impossible for non-blocking syscalls on Linux and (he thinks) on BSD.

[asayers]

• Rebased on master
• Skip retry when timeout has expired

[carllerche]

🎉 CI passes.

Thanks for hanging in there.

[asayers]

Thanks!

[bbshelper]

My application is required to gracefully shutdown itself upon SIGTERM. It does so by changing a global variable in signal handler, and check the variable after poll returns ErrorKind::Interrupted. With this change, poll won't pass that information, breaking my application. Will it be possible to see the old behavior, maybe with a new API?

[carllerche]

Yeah, it would be fine to add a poll_interruptible. Sorry about that.