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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 17 June 2016 at 10:26, 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?

Sleeping threads don't really cost anything beyond the entry they add
in the wakeup table (which we need anyway), and the callback to call
when done (which we also need) so using sleep sounds fine to me!


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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