Re: [MirageOS-devel] mirageos 3.0 : let's break some APIs

[Matthew Gray <matthew.thomas.gray@xxxxxxxxx>]

Hi Mindy, Hannes,

I started working on removing CLOCK and replacing with MCLOCK and PCLOCK (https://github.com/mirage/mirage/issues/442) and ran into a quite a few places where I needed to alter the call to OS.Time.sleep to deal with the int64 nanoseconds value returned by MCLOCK.elapsed_64. I propose that I merge Hannes' changes to add Time.sleep_ns and we merge both as one change. I'm away the next week or so, but I'll hack on this on the way back and we could do the final merging and rebasing at the hackathon?

Matt

On Fri, Jun 17, 2016 at 2:26 AM, Mindy <mindy@xxxxxxxxxxxxxxxxxxx> wrote:

On 06/17/2016 12:12 AM, Hannes Mehnert wrote:

Hello,

instead of doing RANDOM, I started with TIME.  The function sleep now
takes nanoseconds (in form of an int64), instead of seconds as a float:

   https://github.com/mirage/mirage/pull/547

feedback and opinions welcome (there can be more cleanup to get rid of
more float, esp. in the TCP/IP stack (which also depend on Clock (it
should not!)),

Thanks a lot for this PR, and for the work patching downstream users of TIME. :)

To derail a bit, here are the CLOCK dependencies in tcpip:

$ grep -r Make lib/*/*.mli|grep CLOCK
lib/arpv4/arpv4.mli:module Make (Ethif : V1_LWT.ETHIF) (Clock : V1.CLOCK) (Time : V1_LWT.TIME) : sig
lib/ipv6/ipv6.mli:module Make (E : V1_LWT.ETHIF) (T : V1_LWT.TIME) (C : V1.CLOCK) : sig
lib/tcp/flow.mli:module Make (IP:V1_LWT.IP)(TM:V1_LWT.TIME)(C:V1.CLOCK)(R:V1.RANDOM) : sig
lib/tcp/pcb.mli:module Make(Ip:V1_LWT.IP)(Time:V1_LWT.TIME)(Clock:V1.CLOCK)(Random:V1.RANDOM) : sig
lib/tcp/window.mli:module Make(C:V1.CLOCK) : sig

* Arp could be refactored not to use wall-clock time for judging whether to expire entries, but a proper dynamic implementation still needs some dependency on the current TIME signature, I think.
* ipv6 uses the clock for neighbor discovery protocol (lib/ipv6/ndpv6). I *believe* it's the case that, like ARP, this could be refactored to rely only on TIME, but I'm not very familiar with this code and would appreciate other opinions.
* An ICMP implementation that provides timestamps would need CLOCK, as would a TCP that provides timestamps, but as far as I know we're not providing that functionality at the moment and that point is moot.
* Some timers in TCP (lib/tcp/window.mli) currently compare wall clock time to figure out whether they need to act.  Like ARP, I think these could be refactored into sleeping threads, but since this code is much more involved and has higher performance demands I'm hesitant to make the claim boldly.  (There are a number of other apparent uses of Clock in TCP, but they all ultimately lead to invocations Window.Make.)

Our existing use is a consequence of a pattern of implementing timers where we set some mutable state to a timestamp and then have a thread which occasionally compares this mutable state to the current time.  We could replace these with sleeping threads at the cost of increasing the number of threads running in the application, or probably by doing something more clever.  Links to cleverer ideas?

-Mindy

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel