CP-32622: Remove 'select' from stdext

[edwintorok]

Draft, because I need to add some unit tests here.

I'd also like to add a separate function that works only on sockets which is much simpler and uses just 'setsockopt_float'.

[lindig]

could this be a recursive function with any as a parameter which is used for termination?

[lindig]

epoll is not available on macOS; not sure if this is relevant here.

[edwintorok]

We could use iomux if needed, it supports more OSes. If we want to make xe available on more platforms then we should either remove its dependency on stdext, or avoid hard dependencies on epoll.
For now I've updated the template to drop macos.

[edwintorok]

Although contrary to its claim in the package description 'epoll' support isn't actually implement in iomux yet, it is just poll. Although for most purposes that is enough, epoll is useful if you want to watch a large number of FDs in one go (e.g. XAPI webserver)

[edwintorok]

I hadn't noticed that there is already #71 which also has one unit test.
I cherry picked the unit test to this PR and it found a bug: time_limited_read takes an absolute time not relative time as timeout (which means that it always timed out instantly because it interpreted the relative timeout as an absolute time in the distant past).

That is very error prone, so I introduced a time_limited_single_read which takes a relative time as parameter, and this time it is labeled so we know what it is.

Also fixed up the unit test so that it prints the expected and actually measured time instead of just printing 'false', which is very useful for debugging what went wrong.

[psafont]

I cherry picked the unit test to this PR and it found a bug: time_limited_read takes an absolute time not relative time as timeout (which means that it always timed out instantly because it interpreted the relative timeout as an absolute time in the distant past).

That is very error prone, so I introduced a time_limited_single_read which takes a relative time as parameter, and this time it is labeled so we know what it is.

I'll try to find out some time to add a timer module I've been developing lately to module in the date / time package that can be used for timed functions:

module Timer : sig
  (** This module is useful for knowing that a set amount of time has passed
    after some event happened. For example, to know when pasta is cooked al
    dente. *)
  type t

  type remaining = Spare of Mtime.Span.t | Excess of Mtime.Span.t

  val start : timeout:Mtime.Span.t -> t
  (** [start ~timeout] starts a timer that expires after [timeout] has passed.
      The wait is done in monotonic time, not in POSIX time. *)

  val timeout : t -> Mtime.Span.t
  (** [timeout timer] returns the amount of time after which the timer expires,
      from the moment it was started. *)

  val expired : t -> bool
  (** [expired timer] returns whether [timer] has reached the timeout it was
      set to. *)

  val elapsed : t -> Mtime.Span.t
  (** [elapsed timer] returns the amount of time elapsed since [timer] was
      started. *)

  val remaining : t -> remaining
  (** [remaining timer] returns the amount of spare time is left until it
      expires, or the amount of excess time since it expired. *)

  val deadline_of : t -> float
  (** [deadline_of timer] returns the posix timestamp when the timer expires.
      This is an approximation as the timer doesn't take leap seconds into
      account when waiting. The use of this function is discouraged and it's
      only provided for backwards-compatible reasons. *)
end

The implementation can be found in this branch: psafont/xen-api@c9ebc65

[edwintorok]

We'd also need to convert that into whatever form the underlying POSIX API expects, and they may use different clocks.
E.g. 'epoll_wait' (and thus polly) will use monotonic clocks, so that'll match what mtime uses, but XAPI computes a deadline using 'gettimeofday'.

Shouldn't we just merge stdext into XAPI itself? it looks like we might want to refactor some of the APIs, and having them in separate repos like this makes that more difficult (I'd prefer if XAPI used mtime too, but we cannot do that easily without breaking changes, whereas in a monorepo it'd be a lot simpler).

[edwintorok]

Continued in xapi-project/xen-api#5402