[IO] stop using floats for timeouts (lossy)

[fredemmott]

native implementations take seconds/milliseconds/microseconds as integers; for example:

• most unix calls without a timeout take a timeval, which takes int seconds and int microseconds
• Folly async IO (used for stream_await) is available in int millisecond and int microsecond variants
• Float <-> int conversions lead to issues like those addressed by #104

[fredemmott]

@jjergus is there a good/convenient way to deal with these in the datetime proposal?

[jjergus]

There's Time\Interval, an opaque type alias to int, in nanoseconds.

In the current prototype version (which I'll share soon) it would look something like this (for a 3 second timeout):

IO\some_function(..., Time\seconds(3))

Then inside some_function you'd need to call Time\to_raw_ns($timeout) to bypass the opaque type alias.

[lexidor]

There's Time\Interval, an opaque type alias to int, in nanoseconds.

In the current prototype version (which I'll share soon) it would look something like this (for a 3 second timeout):

IO\some_function(..., Time\seconds(3))

Then inside some_function you'd need to call Time\to_raw_ns($timeout) to bypass the opaque type alias.

How would you deal with the situation where I supply a more precise time interval than this API can handle.
If the C(++) functions take milliseconds, but I supply nano seconds.
Do you round, floor, ceil?
What would you do when I supply a non-zero number, but it is rounded to 0?

[fredemmott]

We now have a _Private native that takes nanoseconds, however they are rounded up to milliseconds before passing to folly, as folly internally deals with millis and we want to be sure that its rounded up, not down.

[fredemmott]

How would you deal with the situation where I supply a more precise time interval than this API can handle.

ceil, as the timeout is always a best effort lower bound even if the OS natively supports the requested precision.

[fredemmott]

THis is done, but it should be replaced with an HSL INterval when those are available.