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 <[email protected]> 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 > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
