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

[Thomas Leonard <talex5@xxxxxxxxx>]

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