Xen project Mailing List

On Fri, Jun 26, 2015 at 1:40 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:

On 26 June 2015 at 13:29, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> Le vendredi, 26 juin 2015 Ã 11:18, Thomas Leonard a Ãcrit :
>> let x, set_x = S.create 1
>> let () = ignore (S.map print_int x)
>> let () = Gc.full_major (); List.iter set_x [2; 2; 3]"
>>
>> Under the ref-counting scheme, this program would always print
>> nothing,
>
> Yes.
>
>> because the map signal's refcount is always zero, and it therefore never connects to the x signal.
>
> Yes though I wouldn't see it at "never connects" (at least from an implementation point of view). The `Smap print_int x` call will put the resulting signal into x's dependents (hence "connect" from my point of view), increase `x`'s ref count and the created signal will have a ref count of 0.

Why not delay the connection until the map signal is ref'd? Otherwise
(as you note below) it will leak.

> Now what will happen is that on the first set_x, this signal will end up in the update step but since it has a ref count of 0 we don't update it and remove it from x's dependents and decrease `x`'s ref count by 1. (In fact I'm now realizing that ref count is mostly the length of a node's dependents array, except for the ability to specify that you would like to retain/release or subscribe/unsubscribe a node at the leaves)
>
> Now if you had increased the ref count through a hypothetical S.subscribe call:
>
> let x, set_x = S.create 1
> let () = S.subscribe (S.map print_int x)
> let () = Gc.full_major (); List.iter set_x [2;2;3]
>
> It wouldn't be Gc'd. The only thing I slightly fear with this is that we could get hard to track down leaks: suppose a program does what your did first, and that the x never gets set, the `ignore`d signal will never be gc'd. Though I don't know if that's really relevant in practice.
>
> One option could be to introduce the subscribe/unsubscribe scheme in react and force people to use it but it would do nothing on platforms with weak refs and implement the ref counting, OTOH I tend to prefer if the backends have exactly the same behaviour. For example with your original example in one backend you would see the Division_by_zero (which I still consider fair game, w.r.t. semantics) and in the other not and that would be annoying when you switch backends.
>
>> I guess the more complex case is S.bind, where the bind returning a
>> signal would increase its count (and decrease the count of the
>> previous signal), requiring signals to register and unregister
>> themselves during evaluation. It sounds like it could work, though.
>
> Yes the dynamics is always the tricky part and should be carefully considered, the other tricky part is the delayed nodes used to implement recursive definitions. But I'm certainly to at least try to do this in the future as the situation seems to be really too impractical on _javascript_ if you do dynamics (which is when it eventually becomes *interesting*) and there doesn't seem to be any way of implementing weak refs semantics in _javascript_ in the forseable future.
>
> Also it has always been my goal to have an implementation of FRP that allows to experiment with it to its full extent without being bothered by efficiency issue, now it seems that leaving the life-time of dangling nodes in the hands of the gc can be problematic in practice so we'll see if we can fix that (though I won't change the semantics, at the risk of repeating myself that division by zero should be handled...).
>
> Best,
>
> Daniel

--
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

Re: [MirageOS-devel] Blog post on Irmin/CueKeeper