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
