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

[Mindy <mindy@xxxxxxxxxxxxxxxxxxx>]

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