On Mon, Feb 18, 2013 at 11:01 AM, Patrick Walton wrote:
> This is a good point. There are two issues here:
>
> (1) Ensuring that layout does not retain strong references to DOM nodes
> across layout requests. Since JS GC is not concurrent, we need this
> invariant, as layout runs in a separate tas
This is a good point. There are two issues here:
(1) Ensuring that layout does not retain strong references to DOM nodes across
layout requests. Since JS GC is not concurrent, we need this invariant, as
layout runs in a separate task. Currently layout places references to DOM nodes
inside Rende
On Mon, Feb 18, 2013 at 7:27 AM, Patrick Walton wrote:
> On 2/17/13 3:16 AM, smaug wrote:
>
>> Curious, how does GC manage nodes? Do we explicitly trace even those
>> nodes which don't have js wrappers or do
>> we just use GC for everything in Rust?
>>
>
> All the nodes in Servo have JS wrappers
On Sun, Feb 17, 2013 at 7:26 PM, Patrick Walton wrote:
> On 2/17/13 3:16 AM, smaug wrote:
>
>> Curious, how does GC manage nodes? Do we explicitly trace even those
>> nodes which don't have js wrappers or do
>> we just use GC for everything in Rust?
>>
>
> All the nodes in Servo have JS wrappers
On 2/17/13 3:16 AM, smaug wrote:
Curious, how does GC manage nodes? Do we explicitly trace even those
nodes which don't have js wrappers or do
we just use GC for everything in Rust?
All the nodes in Servo have JS wrappers at the moment, and their
lifetimes are managed by the JS garbage collect
On 02/16/2013 08:50 PM, Patrick Walton wrote:
I have started work a new DOM implementation in the "dom" branch. It is
currently building except for an internal compiler error, the fix for which is
currently being upstreamed to Rust.
This new DOM implementation is based on structs instead of enu
6 matches
Mail list logo
