In the department-of-paying-down-technical-debt, I'm planning to remove
much of the Chromium event loop over the next few months. You can follow
along in bug 1260828.
The rough outline:
Step 1: Replace Task with nsIRunnable, without changing any other
semantics. This will happen in late April, a
On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
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 po
On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd wrote:
> On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
> 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
On Wed, Mar 30, 2016 at 1:48 PM, Eric Rescorla wrote:
> On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd wrote:
>
> > On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
> > wrote:
> > > I've been unhappy with the fact that our event loop uses refcounted
> > objects
> > > by default. *Most* runnabl
On Wed, Mar 30, 2016 at 2:03 PM, Bobby Holley wrote:
> On Wed, Mar 30, 2016 at 1:48 PM, Eric Rescorla wrote:
>
>> On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd wrote:
>>
>> > On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
>> > wrote:
>> > > I've been unhappy with the fact that our event lo
On Wed, Mar 30, 2016 at 11:34 AM, Benjamin Smedberg
wrote:
> I support this plan!
>
> Mostly.
>
> 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'm asking you to cons
On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd wrote:
> On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
> 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
On 3/30/2016 20:21, Kyle Huey wrote:
In the department-of-paying-down-technical-debt, I'm planning to remove
much of the Chromium event loop over the next few months. You can follow
along in bug 1260828.
The rough outline:
Step 1: Replace Task with nsIRunnable, without changing any other
semant
On 31/03/2016 07:42, Kyle Huey wrote:
> I'll pose to you the same question I posed bsmedberg, is this actually
> worth fiddling with all the existing runnables.
I did some testing around a couple of years ago and the answer is the
same as usual: it depends. On modern x86 machines I doubt one would
On Wednesday, March 30, 2016 at 1:28:18 PM UTC-5, Kyle Huey wrote:
> The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
> involve varying levels of platform specific event loop or API integration
> that will probably be more difficult to untangle. They also won't block my
> long-t
On Thu, Mar 31, 2016 at 8:08 AM, Gabriele Svelto wrote:
> On this topic, did anyone experiment with trying to lighten the
> synchronization burden when handling nsEventQueues? Both nsThread and
> nsThreadPool acquire a mutex each time we need to get the next runnable;
> we could pull out all pendi
On Thu, Mar 31, 2016 at 6:43 AM, Nathan Froyd wrote:
> On Thu, Mar 31, 2016 at 8:08 AM, Gabriele Svelto
> wrote:
> > On this topic, did anyone experiment with trying to lighten the
> > synchronization burden when handling nsEventQueues? Both nsThread and
> > nsThreadPool acquire a mutex each tim
On 31-03-16 15:17, Jim Mathies wrote:
> On Wednesday, March 30, 2016 at 1:28:18 PM UTC-5, Kyle Huey wrote:
>> The other types (TYPE_UI, TYPE_IO, and
>> TYPE_MOZILLA_NONMAINUITHREAD) involve varying levels of platform
>> specific event loop or API integration that will probably be more
>> difficult
On 3/31/16 8:08 AM, Gabriele Svelto wrote:
On this topic, did anyone experiment with trying to lighten the
synchronization burden when handling nsEventQueues?
This has come up in profiles recently too. For example
https://bugzilla.mozilla.org/show_bug.cgi?id=1254240#c6 shows us
acquiring and
On Thu, Mar 31, 2016 at 3:19 AM, Honza Bambas wrote:
> On 3/30/2016 20:21, Kyle Huey wrote:
>
>> In the department-of-paying-down-technical-debt, I'm planning to remove
>> much of the Chromium event loop over the next few months. You can follow
>> along in bug 1260828.
>>
>> The rough outline:
>>
15 matches
Mail list logo