[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 23 June 2015 at 16:44, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> Le mardi, 23 juin 2015 Ã 16:08, Thomas Leonard a Ãcrit :

>> I should probably replace most of the binds with this (being careful
>> that they don't return an existing signal, though).
> Yes that's the reason why I prefer weak references no need to ask yourself 
> such questions.
>> Can we define "A handler that isn't needed" as "A handler that would
>> be garbage collected if the GC ran now"?
>> (or, if we had a glabal sink, "A handler that isn't a dependency of
>> the global sink")
> I'm not totally sure about what I'm going to write as I haven't got these 
> things in my head. But I'm wondering if we couldn't maybe replace the weak 
> refs by a reference counting mechanism (FRP is a dag of nodes, no cycle 
> problems) and perform strong stops on the node once the count reaches `0`. 
> The only thing that would be needed is a retain/release on the output nodes. 
> retain you already need to do it in some way (otherwise your node gets gc'd). 
> You'd still need to do releases but this would be hidden behind the 
> sinks-like setters.

Sounds reasonable. To check I understand, taking this example from the
React docs:

"It is important to keep references on effectful events and signals.
Otherwise they may be reclaimed by the garbage collector. The
following program prints only a 1.

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, because the map signal's refcount is always zero, and it
therefore never connects to the x signal. It will be GC'd, but that
won't affect its behaviour, since it wasn't doing anything anyway.

With your Stdout module (or some other way to increment the ref
counter) we'd have:

let x, set_x = S.create 1
let () = Stdout.set (S.map string_of_int x)
let () = Gc.full_major (); List.iter set_x [2; 2; 3]"

This would always print all the values of x.

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.

Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.