NOTE: This is a non backward compatible change. Specifically, env#clock is no longer there. Additionally, the Eio.Time.clock now also requires 'a generic parameter. Any advice on how to go about maintaining backwards compatibility would be greatly appreciated.

@talex5

NOTE: This is a non backward compatible change. Specifically, env#clock is no longer there. Additionally, the Eio.Time.clock now also requires 'a generic parameter. Any advice on how to go about maintaining backwards compatibility would be greatly appreciated.

You can keep Stdenv.clock, but mark it deprecated (but it doesn't look like it's possible to get a compile-time warning about env#clock).

As we're not at Eio 1.0 yet, it's OK to break the API if it's difficult to avoid it, like here.

However, if you did want to avoid that it would be possible to add a new Clock module with the new API e.g.

module Clock : sig
  type 'a t = ...
  ...
end

module Time : sig
  type clock = float Clock.t
  ...
  (* deprecated functions here *)
end

I have rebased on master now.

As we're not at Eio 1.0 yet, it's OK to break the API if it's difficult to avoid it, like here.

Thanks. Yes, I would like to keep the current API set since every other option introduces un-necessary cruft.

Could you please approve/merge if there are no further objections.

@talex5 the PR has been rebased to the latest master.

Now #338 is merged, the remaining parts of this PR (e.g. the use of Ptime) need rebasing on top of that.

@talex5 It seems this PR has bit rotted quite a bit. Do we still want to use the actual clock to implement timeout functionality, i.e. if mono then we use mono clock, if sys then we use real/sys clock and so forth. If so, I will open another PR rather than continue with this one. Also I believe ocaml-multicore/ocaml-uring#79 in ocaml-uring is required to implement such functionality at least in uring backend.

Updating the benchmarks to use monotonic times sounds good.

Getting eio_linux to use the realtime clock directly would be good too, fixing this comment:

I don't see why that needs ocaml-multicore/ocaml-uring#79. We can just use the new Uring.timeout with Realtime, I think.

Closing this PR and opening new ones is fine with me.

I don't see why that needs ocaml-multicore/ocaml-uring#79. We can just use the new Uring.timeout with Realtime, I think.

My memory is a bit hazy at the moment regarding this. However, the last time I tried this PR, I believe I realized that eventually, timeout value drills down to this bit of code as well.

IIRC the clock defaults to CLOCK_MONOTONIC, in order to change/improve on that I think I opened that uring PR.

You don't need to (and can't) use Uring.wait's timeout for real-time timeouts. You can just submit them as their own separate operations instead. I don't see what completion counts have to do with this either.

1. Submit a Realtime timeout to the ring, just like any other operation.
2. When it's done, Uring.wait will return and it will be processed like any other operation.
3. If you need to cancel, send a cancel message, like cancelling other uring operations.

Closing this since it has bit rotted quite a bit now.