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

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

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

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