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

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

Le vendredi, 26 juin 2015 Ã 14:30, Thomas Leonard a Ãcrit :
> - the map signals would be created with ref counts of zero and not connected
> (i.e. each signal holds a reference to its input signal, but not the
> other way around)

Ah yes why not. But one problem with the ref counting approach is that it would 
violate the semantics, going back to what I was proposing this is problematic:

let x1, set_x1 = S.create 1
let x2 = S.map ((+) 1) x1
let () = set_x1 2 (* this will not update x2 and remove x2 from x1's dependents 
*).  
let () =
  (* here we would be diconnected from x1, this would however not  
      be the case with your proposal, but we still have the semantic problem 
that x2  
      never saw x1 changing to 2 *)  
  S.subscribe (S.map print_int x2)  
let () = List.iter set_x [3;4]


So there must be some kind of shady condition to tell to the clients like "your 
signals will not be up to date if they are not an internal node of the FRP 
graph or have been subscribed to". But I'm not sure I like that very much, it's 
still going back to have to think about memory management. Though one could say 
that maybe that kind of code above is unlikely to happen if you program the FRP 
way.

In any case with ref counting, the connection approach you mention above would 
maybe have better properties (avoid total graph disconnection).

Daniel

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