Re: Removing the Chromium event loop

2016-03-31 Thread Kyle Huey
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: >>

Re: Removing the Chromium event loop

2016-03-31 Thread Boris Zbarsky
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

Re: Removing the Chromium event loop

2016-03-31 Thread Gian-Carlo Pascutto
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

Re: Removing the Chromium event loop

2016-03-31 Thread Kyle Huey
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

Re: Removing the Chromium event loop

2016-03-31 Thread Nathan Froyd
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

Re: Removing the Chromium event loop

2016-03-31 Thread Jim Mathies
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

Re: Removing the Chromium event loop

2016-03-31 Thread Gabriele Svelto
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

Re: Removing the Chromium event loop

2016-03-31 Thread Honza Bambas
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

Re: Removing the Chromium event loop

2016-03-30 Thread Kyle Huey
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

Re: Removing the Chromium event loop

2016-03-30 Thread Kyle Huey
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

Re: Removing the Chromium event loop

2016-03-30 Thread Eric Rescorla
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

Re: Removing the Chromium event loop

2016-03-30 Thread Bobby Holley
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

Re: Removing the Chromium event loop

2016-03-30 Thread Eric Rescorla
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

Re: Removing the Chromium event loop

2016-03-30 Thread Nathan Froyd
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