On Wed, Mar 30, 2016 at 2:03 PM, Bobby Holley <bobbyhol...@gmail.com> wrote:

> On Wed, Mar 30, 2016 at 1:48 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd <nfr...@mozilla.com> wrote:
>>
>> > On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
>> > <benja...@smedbergs.us> wrote:
>> > > I've been unhappy with the fact that our event loop uses refcounted
>> > objects
>> > > by default. *Most* runnables are pure-C++ and really don't need to be
>> > > refcounted/scriptable.
>> >
>> > I've been thinking about this too.  gfx has a separate thread pool
>> > that was created partly because of the desire to be Gecko-free and
>> > partly because of the overhead that nsIRunnable has.  It would be nice
>> > to eliminate one of those objections.  Making this change would also
>> > bring down bloat from vtables and essentially-useless methods.
>> >
>> > > I'm asking you to consider unifying these two things by making our
>> event
>> > > loop work more like chromium and just using c++ objects without a
>> > refcount
>> > > by default? Then to post a scriptable event to an event loop you'd
>> have
>> > to
>> > > have it own a separate scriptable object.
>> >
>> > I'd like to make this happen if Kyle doesn't.
>> >
>>
>> Do we have measurements that demonstrate that this would have a
>> substantially
>> positive performance impact? Generally, the world would be safer if we
>> always
>> used smart pointers rather than bare pointers, so it seems like we should
>> have
>> some strong evidence before pushing in the other direction.
>>
>
> I'm assuming that we would use some sort of UniquePtr-ish owning semantics
> rather than raw pointers.
>

This would certainly be acceptable. My objection is merely to raw pointers.


> That said, I think most of the overhead from having things be refcounted
> comes when AddRef and Release are virtual. We can solve that problem on its
> own by making the superclass concrete with a refcount member, and hoisting
> the reference counting onto it with statically-dispatched methods.
>

Yes, this would also be fine.

-Ekr




> bholley
>
>
>>
>> -Ekr
>>
>>
>> >
>> > -Nathan
>> > _______________________________________________
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> _______________________________________________
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to