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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 26 June 2015 at 14:20, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> Le vendredi, 26 juin 2015 Ã 13:40, Thomas Leonard a Ãcrit :
>> Why not delay the connection until the map signal is ref'd? Otherwise
>> (as you note below) it will leak.
>
> I'm not sure how this could be done without having to manage all connections 
> explicitly by the client of the library (which is out of question) ?

Well, I haven't thought this through too much, but if you had e.g.

let x1, set_x1 = S.create 1
let x2 = S.map ((+) 1) x1
let x3 = S.map ((+) 1) x2
let () = S.subscribe (S.map print_int x3)
let () = Gc.full_major (); List.iter set_x [2;2;3]

Then I imagine:

- 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)
- the final subscribe refs the print_int signal, which then connects
to x3, which connects to x2 and so on.

If you S.unsubscribe the map signal then they all disconnect again.

In that case it doesn't seem like there's any extra management to do
(just the final subscribe, as before).


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