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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 26 June 2015 at 15:44, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> 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.

Hmm, yes, this could be a problem for handlers that expect to see all states.
S.diff would be a problem too (and sometimes you might want to diff
against the last seen value of the signal rather than the previous
actual value).

In the case of CueKeeper, it would be an advantage though. For
example, there are multiple tabs, each of which shows a different
query. The FRP code (since replaced) was something like this:

let tab_content =
  S.bind current_tab (function
    | `Process -> process_tab
    | `Work -> work_tab
    ...
  ) in

The problem was that it recalculated every tab's query each time,
whereas I only wanted it to calculate the elements for the tab that
was currently selected.

> In any case with ref counting, the connection approach you mention above 
> would maybe have better properties (avoid total graph disconnection).
>
> 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