Use better types for all timeout arguments

[Susurrus]

It looks like there may be other work on this area from perusing the existing issues and PRs, so maybe this is covered by that work already, but I wanted to use a Duration (or equivalent) for poll::poll(). Looks like there are a number of functions that could use this type treatment:

• poll::poll()
• event::kevent() (though this looks like a backcompat issue)
• epoll::epoll_wait()

I'm not certain if there are rationales for why this hasn't been done already since it looks like some functions have been converted to use TimeSpec/TimeVal already.

[kamalmarhubi]

I think part of the rationale was wanting to support old versions of Rust. Duration was only added in 1.3.0, and for a long time we supported back to 1.1.0. I think we now support ~1.7.0 so this could be revisited. @nix-rust/nix-maintainers thoughts?

[arcnmx]

If the type is stable in all supported Rust versions, definite +1 to using proper time/duration types as arguments.

[posborne]

Yeah, no objection from me.

[Susurrus]

This brings up an interesting point, both for users and developers, that the minimum supported rust version isn't explicitly stated anywhere, though your CI only tests Rust 1.7. Can this be added to the readme?

[posborne]

Can this be added to the readme?

That seems reasonable. I do believe we have tried to make a note of any changes to supported version in the changelog.

[kamalmarhubi]

1.7 is the current minimum, I believe.

Re taking Duration, I'd suggest taking Into<Duration> or perhaps Into<TimeVal> / Into<TimeSpec> as appropriate for the function.

[Susurrus]

Why not just use Duration everywhere? #511 shows that if helper methods are desired they can just be implemented for Duration instead of introducing a new type. Or am I missing something and it's inappropriate or unergonomic in some cases?

[Susurrus]

@posborne @kamalmarhubi Any comments on this?

[posborne]

I agree that taking Duration would be more ergonomic and would be in favor of taking Into<Duration> (which will work just fine with a Duration due to reflexivity). The only minor downside would be that we might need to do conversions more frequently if a syscall is made frequently (but even then the conversion overhead is approximately nothing compared to the syscall in most cases).

[Susurrus]

Would Rust be able to optimize across Into<Duration>? So we can have keep the nix-specific TimeVal and it contains the most common representation and if the Duration is converted back before use within a function, then Rust could optimize that out and no conversion would be done if you do back-to-back calls?