[chromium-dev] buildbot failure in Chromium on Chromium Linux, revision 35779

[buildbot]

Automatically closing tree for "test_shell_tests" on "Chromium Linux"

http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux/builds/8936

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Linux

--=>  Automatically closing tree for "test_shell_tests" on "Chromium Linux"  
<=--

Revision: 35779
Blame list: tyosh...@google.com

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Peter Kasting]

On Thu, Jan 7, 2010 at 8:00 PM, Michael Nordman  wrote:

> Where as It looks like GURL::EmptyGURL() may be a tad less costly than
> GURL().
>

Not if you ever need to initialize another GURL with it (since the compiler
can't collapse the copy).  Which is true much of the time that EmptyGURL()
can be replaced by GURL().

And the code clarity reasons still stand.  Please don't do this in the name
of hoping you'll save an instruction somewhere, it's much like premature
optimization.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Michael Nordman]

On Thu, Jan 7, 2010 at 4:02 PM, Darin Fisher  wrote:

> On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman  wrote:
>
>> On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting 
>> wrote:
>> > If you have ever used any of the EmptyXXX() functions, or ever will,
>> please
>> > read on.
>> > These functions (in string_util.h and gurl.h) are meant for a single,
>> > specific use case:
>> > const std::string& MyClass::foo() const {
>> >   return (everything == OK) ? member_string : EmptyString();
>> > }
>> > Here you cannot return "string()", because it's destroyed before the
>> > function returns, and the caller receives garbage; and you don't want to
>> > have the function return by value, because you can access the member
>> > variable directly and save a copy.  The utility functions give you a
>> global
>> > empty string that you can safely return a const reference to.
>> > DON'T USE THESE OUTSIDE THIS CASE.  You should never use these as
>> > initializers, arguments to functions, or return values in functions that
>> > return by value.  Just use the default constructor; that's what it's
>> there
>> > for.
>>
>> Out of curiosity, what is wrong with using EmptyString() in those
>> cases? Is there a correctness problem? Unnecessary inclusion of
>> string_util.h?
>>
>>
> probably just a tad more costly since it involves Singleton.  but, i
> think peter's main reason was simply to stick to the simpler and more
> familiar std::string.
>
> -darin
>

Where as It looks like GURL::EmptyGURL() may be a tad less costly than
GURL().


>
>
>
>
>> - a
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Where does documentation intended for non-developers go?

[Nico Weber]

On Thu, Jan 7, 2010 at 5:31 PM, Evan Martin  wrote:
> On Thu, Jan 7, 2010 at 2:31 PM, Nico Weber  wrote:
>> I wrote up a document that's relevant not only for people working on
>> chromium, but for (small parts of) the world in general ("under which
>> circumstances does google chrome display idn urls as punycode?" I
>> mean, who's not dying to know?).
>>
>> Where do documents like these go?
>
> We used to have a technical FAQ

Where was it at?

> but I deleted it because it was
> embarrassingly out of date ("When's the Mac port coming out?").  I
> think we could profitably use one again.  For example, "Why does
> Chrome give a warning about .exe downloads on Linux?" is definitely a
> FAQ I get.
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Linux Builder (ChromiumOS), revision 35770

[buildbot]

Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Builder%20%28ChromiumOS%29/builds/2050

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Builder%20%28ChromiumOS%29

--=>  Automatically closing tree for "compile" on "Linux Builder (ChromiumOS)"  
<=--

Revision: 35769, 35770
Blame list: ana...@chromium.org,tk...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Build issue GL/glu.h

[Adam Langley]

On Thu, Jan 7, 2010 at 8:14 AM, Aaron  wrote:
> Any idea what could be causing this thing?  It's been going on for
> some time now.  All of my research turns up nothing.

piman writes:

For the incoming gpu plugin on linux, the following new packages are needed:
  * mesa-common-dev
  * libgl1-mesa-dev
  * libglu1-mesa-dev

The gpu plugin change is not checked in yet (some of the slaves didn't
get those packages), but will shortly (hopefully tomorrow), so you
should go ahead and install those packages now. I updated
http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites
and build/install-build-deps.sh
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Build issue GL/glu.h

[Lei Zhang]

See the email from 3 days ago titled "PSA: new dev packages needed on linux"

On Thu, Jan 7, 2010 at 8:14 AM, Aaron  wrote:
> Any idea what could be causing this thing?  It's been going on for
> some time now.  All of my research turns up nothing.
>
> CXX(target) out/Release/obj.target/command_buffer_service/gpu/
> command_buffer/service/gles2_cmd_decoder.o
> In file included from ./gpu/command_buffer/common/gles2_cmd_format.h:
> 16,
>                 from gpu/command_buffer/service/gles2_cmd_decoder.cc:
> 15:
> third_party/glew/include/GL/glew.h:1476:20: error: GL/glu.h: No such
> file or directory
> make: *** [out/Release/obj.target/command_buffer_service/gpu/
> command_buffer/service/gles2_cmd_decoder.o] Error 1
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Victor Khimenko]

On Fri, Jan 8, 2010 at 1:51 AM, Albert J. Wong (王重傑) wrote:

> On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher  wrote:
>
>>
>> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow  wrote:
>>
>>> (As discussed during lunch...)  Why not just do this in this case and
>>> remove EmptyString() altogether?
>>>
>>> const std::string& MyClass::foo() const {
>>>   static std::string empty = EmptyString();
>>>   return (everything == OK) ? member_string : empty;
>>> }
>>>
>>>
>> This is not thread safe.  EmptyString() uses Singleton to basically
>> achieve the same thing in a thread safe manner.
>>
>
> Is there something wrong with returning by copy, and relying on the
> compiler
> to execute a return value optimization?
>
> Do you volunteer to rewrite the compilers to  implement said optimization?
GCC, for one will not do so.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Build issue GL/glu.h

[Aaron]

Any idea what could be causing this thing?  It's been going on for
some time now.  All of my research turns up nothing.

CXX(target) out/Release/obj.target/command_buffer_service/gpu/
command_buffer/service/gles2_cmd_decoder.o
In file included from ./gpu/command_buffer/common/gles2_cmd_format.h:
16,
 from gpu/command_buffer/service/gles2_cmd_decoder.cc:
15:
third_party/glew/include/GL/glew.h:1476:20: error: GL/glu.h: No such
file or directory
make: *** [out/Release/obj.target/command_buffer_service/gpu/
command_buffer/service/gles2_cmd_decoder.o] Error 1
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Red Tree 2010/1/6

[Chase Phillips]

I'll take the bug for now to identify the WebKit rev that caused the
regression.

On Wed, Jan 6, 2010 at 20:10, Robert Sesek  wrote:

> Good evening,
>
> At 9pm ET, the tree was significantly red and Erik Kay closed the tree: Win
> browser_tests, Win & Mac perf, Linux views, and Win Webkit all were red. I
> cleaned up the Win browser_tests, Linux Views, and Win WebKit redness, but
> the Win & Mac perf regressions are still in play. mpcompete, jamesr, and I
> debated about what to do with this since it originated from a fairly
> significant WebKit roll:
> http://src.chromium.org/viewvc/chrome?view=rev&revision=35646. Backing out
> didn't seem like the best option because it was large jump and another roll
> happened later at r35669. The tree *is still closed* as of 11pm ET because
> http://crbug.com/31698 (tracking bug for this perf regression) does not
> yet have an owner and it desperately needs one! If in the morning someone
> more knowledgeable feels like we can open, please do.
>
> Also, I didn't have time to track it down tonight, but Windows UI
> Interactive (dbg) has been red on and off for the past couple of cycles,
> starting at
> http://build.chromium.org/buildbot/waterfall/builders/Interactive%20Tests%20(dbg)/builds/19501.
> I'm hesitant to mark it as flaky without knowing a little more, but I backed
> out oshima's change (the likely candidate) and the redness continued. Help
> appreciated :).
>
> Thanks and good night!
>
> rsesek / @chromium.org
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Victor Khimenko]

On Fri, Jan 8, 2010 at 2:10 AM, Albert J. Wong (王重傑) wrote:

>
> According to wikipedia,
> http://en.wikipedia.org/wiki/Return_value_optimization, msvc, g++, and
> icc, all support it...or am I missing something about this situation that
> makes RVO inapplicable?
>
> Yes. Starting from version 3.1: http://gcc.gnu.org/gcc-3.1/changes.html

> G++ now supports the "named return value optimization": for code like
>
> A f () {
>   A a;
>   ...
>   return a;
> }
>
>
> G++ will allocate a in the return value slot, so that the return becomes a
> no-op. For this to work, all return statements in the function must return
> the same variable
>
The limitation is still true AFAIK. Many compilers give up early in case
where function can return two objects depending on some condition.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Red Tree 2010/1/6

[Chase Phillips]

Adam reverted WebKit r52847 which appears to fix the regression.  In
Chromium's r35744, Dimitri picked up Adam's fix, perf tests are green now.
 Thanks Adam and Dimitri!

On Thu, Jan 7, 2010 at 11:13, Chase Phillips  wrote:

> I'll take the bug for now to identify the WebKit rev that caused the
> regression.
>
> On Wed, Jan 6, 2010 at 20:10, Robert Sesek  wrote:
>
>> Good evening,
>>
>> At 9pm ET, the tree was significantly red and Erik Kay closed the tree:
>> Win browser_tests, Win & Mac perf, Linux views, and Win Webkit all were red.
>> I cleaned up the Win browser_tests, Linux Views, and Win WebKit redness, but
>> the Win & Mac perf regressions are still in play. mpcompete, jamesr, and I
>> debated about what to do with this since it originated from a fairly
>> significant WebKit roll:
>> http://src.chromium.org/viewvc/chrome?view=rev&revision=35646. Backing
>> out didn't seem like the best option because it was large jump and another
>> roll happened later at r35669. The tree *is still closed* as of 11pm ET
>> because http://crbug.com/31698 (tracking bug for this perf regression)
>> does not yet have an owner and it desperately needs one! If in the morning
>> someone more knowledgeable feels like we can open, please do.
>>
>> Also, I didn't have time to track it down tonight, but Windows UI
>> Interactive (dbg) has been red on and off for the past couple of cycles,
>> starting at
>> http://build.chromium.org/buildbot/waterfall/builders/Interactive%20Tests%20(dbg)/builds/19501.
>> I'm hesitant to mark it as flaky without knowing a little more, but I backed
>> out oshima's change (the likely candidate) and the redness continued. Help
>> appreciated :).
>>
>> Thanks and good night!
>>
>> rsesek / @chromium.org
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Where does documentation intended for non-developers go?

[Evan Martin]

On Thu, Jan 7, 2010 at 2:31 PM, Nico Weber  wrote:
> I wrote up a document that's relevant not only for people working on
> chromium, but for (small parts of) the world in general ("under which
> circumstances does google chrome display idn urls as punycode?" I
> mean, who's not dying to know?).
>
> Where do documents like these go?

We used to have a technical FAQ but I deleted it because it was
embarrassingly out of date ("When's the Mac port coming out?").  I
think we could profitably use one again.  For example, "Why does
Chrome give a warning about .exe downloads on Linux?" is definitely a
FAQ I get.
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Darin Fisher]

On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman  wrote:

> On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting  wrote:
> > If you have ever used any of the EmptyXXX() functions, or ever will,
> please
> > read on.
> > These functions (in string_util.h and gurl.h) are meant for a single,
> > specific use case:
> > const std::string& MyClass::foo() const {
> >   return (everything == OK) ? member_string : EmptyString();
> > }
> > Here you cannot return "string()", because it's destroyed before the
> > function returns, and the caller receives garbage; and you don't want to
> > have the function return by value, because you can access the member
> > variable directly and save a copy.  The utility functions give you a
> global
> > empty string that you can safely return a const reference to.
> > DON'T USE THESE OUTSIDE THIS CASE.  You should never use these as
> > initializers, arguments to functions, or return values in functions that
> > return by value.  Just use the default constructor; that's what it's
> there
> > for.
>
> Out of curiosity, what is wrong with using EmptyString() in those
> cases? Is there a correctness problem? Unnecessary inclusion of
> string_util.h?
>
>
probably just a tad more costly since it involves Singleton.  but, i
think peter's main reason was simply to stick to the simpler and more
familiar std::string.

-darin




> - a
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Peter Kasting]

On Thu, Jan 7, 2010 at 3:45 PM, Aaron Boodman  wrote:

> Out of curiosity, what is wrong with using EmptyString() in those
> cases? Is there a correctness problem? Unnecessary inclusion of
> string_util.h?


There are a couple reasons.  Code clarity and consistency is a primary one;
using EmptyString() implies you _need_ EmptyString() and that the default
constructor won't work, which can be confusing.  (I am especially frustrated
with code like "std::string x(EmptyString());".)  For folks used to using
WebKit string classes, which differentiate between empty and NULL, this can
look like you're saying more about the semantics of the statement than you
actually are.  If you see code with hundreds of EmptyString()s you begin
wondering whether your code should use it too.

Another reason is that EmptyString() does a threadsafe access to a global
object, whereas the default constructor is a comparatively simple block of
inlinable code that the compiler understands and may frequently be able to
optimize better.

There is not a correctness issue, which is why uses of this can seep into
the codebase without people noticing.  It is, of course, nice to avoid
including string_util.h as you mention, though I'd consider that a minor
benefit.

The totality of the reasons is somewhat lost (to me at least) in the mists
of time; EmptyString() dates from the earliest days of the codebase, and at
the time we went round and round a number of times to determine the best
solutions for each situation.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Aaron Boodman]

On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting  wrote:
> If you have ever used any of the EmptyXXX() functions, or ever will, please
> read on.
> These functions (in string_util.h and gurl.h) are meant for a single,
> specific use case:
> const std::string& MyClass::foo() const {
>   return (everything == OK) ? member_string : EmptyString();
> }
> Here you cannot return "string()", because it's destroyed before the
> function returns, and the caller receives garbage; and you don't want to
> have the function return by value, because you can access the member
> variable directly and save a copy.  The utility functions give you a global
> empty string that you can safely return a const reference to.
> DON'T USE THESE OUTSIDE THIS CASE.  You should never use these as
> initializers, arguments to functions, or return values in functions that
> return by value.  Just use the default constructor; that's what it's there
> for.

Out of curiosity, what is wrong with using EmptyString() in those
cases? Is there a correctness problem? Unnecessary inclusion of
string_util.h?

- a
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[王重傑]

[ resending from correct e-mail ]


> If you are saying that everywhere in the code can return by value instead
> of by const ref and the compiler will optimize it equivalently, you are
> wrong; I was under the same misapprehension until yesterday.  We've verified
> that even in the best case
>

That's what I was indeed what I was thinking, and apparently, it was a bad
assumption. :-/

Thanks for the explanation.

 -Albert
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Peter Kasting]

On Thu, Jan 7, 2010 at 2:50 PM, Albert Wong (王重傑)  wrote:

> Is there something wrong with returning by copy, and relying on the
> compiler to execute a return value optimization?
>

I'm not totally sure what your comment is saying.

If you are saying that everywhere in the code can return by value instead of
by const ref and the compiler will optimize it equivalently, you are wrong;
I was under the same misapprehension until yesterday.  We've verified that
even in the best case (full optimizations, all functions visible to the
compiler, simple bodies), returning a member by value instead of by const
ref takes more code.

If you are saying that the RVO exists and matters, then of course you're
correct.  When you write code like this:

std::string foo() {
  std::string a;
  // Calculations with a
  return a;
}

...The compiler uses the RVO to avoid copying |a| to the return value at
EOF, and instead just allocate |a| directly to the return slot.  This is why
we prefer return-by-value to return-by-outparam where possible: RVO makes it
just as cheap, and clearer.  But neither is as cheap as return-by-const-ref
if you've already got the referenced object sitting around, as you do on
class member accessors; it's one copy versus zero.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[王重傑]

On Thu, Jan 7, 2010 at 2:53 PM, Victor Khimenko  wrote:

>
> On Fri, Jan 8, 2010 at 1:51 AM, Albert J. Wong (王重傑) 
> wrote:
>
>> On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher  wrote:
>>
>>>
>>> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow wrote:
>>>
 (As discussed during lunch...)  Why not just do this in this case and
 remove EmptyString() altogether?

 const std::string& MyClass::foo() const {
   static std::string empty = EmptyString();
   return (everything == OK) ? member_string : empty;
 }


>>> This is not thread safe.  EmptyString() uses Singleton to basically
>>> achieve the same thing in a thread safe manner.
>>>
>>
>> Is there something wrong with returning by copy, and relying on the
>> compiler
>> to execute a return value optimization?
>>
>> Do you volunteer to rewrite the compilers to  implement said optimization?
> GCC, for one will not do so.
>

According to wikipedia,
http://en.wikipedia.org/wiki/Return_value_optimization, msvc, g++, and icc,
all support it...or am I missing something about this situation that makes
RVO inapplicable?

-Albert
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[王重傑]

On Thu, Jan 7, 2010 at 2:46 PM, Darin Fisher  wrote:

>
>
> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow  wrote:
>
>> (As discussed during lunch...)  Why not just do this in this case and
>> remove EmptyString() altogether?
>>
>> const std::string& MyClass::foo() const {
>>   static std::string empty = EmptyString();
>>   return (everything == OK) ? member_string : empty;
>> }
>>
>>
> This is not thread safe.  EmptyString() uses Singleton to basically
> achieve the same thing in a thread safe manner.
>

Is there something wrong with returning by copy, and relying on the compiler
to execute a return value optimization?

-Albert
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Fady Samuel]

Perhaps a silly question but what about plugins? Charlie mentioned in his
paper that plugins run in a separate process.

Does the renderer also respond to draw requests from plugins such as Flash?
So by running the renderer asynchronously from script, maybe one can allow
it to respond more rapidly to plugins? Faster Flash perhaps?

Fady

On Thu, Jan 7, 2010 at 4:33 PM, Peter Kasting  wrote:

> On Thu, Jan 7, 2010 at 1:30 PM, Fady Samuel  wrote:
>
>> What about allowing the renderer to run asynchronously with the
>> script?  Right now you're either producing the view or you're running script
>> but never both concurrently, correct?  Parallelizing them should not
>> introduce issues I think (assuming the renderer has the equivalent of a
>> snapshot view of the DOM tree)?
>>
>
> But the chief use of JS is to manipulate the DOM.  There's little real
> parallelism to extract there, and great cost to doing so.
>
> PK
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Darin Fisher]

On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow  wrote:

> (As discussed during lunch...)  Why not just do this in this case and
> remove EmptyString() altogether?
>
> const std::string& MyClass::foo() const {
>   static std::string empty = EmptyString();
>   return (everything == OK) ? member_string : empty;
> }
>
>
This is not thread safe.  EmptyString() uses Singleton to basically
achieve the same thing in a thread safe manner.

-Darin



> I forget if this runs the constructor on first use or when the app starts
> up.  If it's the latter and you care, you can even just make it a null
> pointer and allocate it on first use.
>
> No matter what PSA or comments you write, someone will use it again if it's
> there.
>
> J
>
> On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting  wrote:
>
>> If you have ever used any of the EmptyXXX() functions, or ever will,
>> please read on.
>>
>> These functions (in string_util.h and gurl.h) are meant for a single,
>> specific use case:
>>
>> const std::string& MyClass::foo() const {
>>   return (everything == OK) ? member_string : EmptyString();
>> }
>>
>> Here you cannot return "string()", because it's destroyed before the
>> function returns, and the caller receives garbage; and you don't want to
>> have the function return by value, because you can access the member
>> variable directly and save a copy.  The utility functions give you a global
>> empty string that you can safely return a const reference to.
>>
>> DON'T USE THESE OUTSIDE THIS CASE.  You should never use these as
>> initializers, arguments to functions, or return values in functions that
>> return by value.  Just use the default constructor; that's what it's there
>> for.
>>
>> I have a change out for review that removes the erroneous uses of these
>> from our codebase and clarifies the comment on their declaration, but it's
>> worth calling this out directly so they don't creep back in.
>>
>> PK
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Where does documentation intended for non-developers go?

[Nico Weber]

Hi,

I wrote up a document that's relevant not only for people working on
chromium, but for (small parts of) the world in general ("under which
circumstances does google chrome display idn urls as punycode?" I
mean, who's not dying to know?).

Where do documents like these go?

Nico
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Fady Samuel]

Which brings me back to the original topic of replicated state. Is there any
reason not to have a single monolithic cache (or other similar state) across
all processes other than synchronization issues or fault tolerance?

I have a technique to give me a consistent, "snapshot" view of data
structures without actually creating a copy of the data structure (a form of
concurrent, robust iterator I'm calling a strongly consistent iterator). The
shared data structure itself can also be made fault tolerant despite being
shared.

That way, two site instances can share images, scripts, etc.

Thanks,

Fady

On Thu, Jan 7, 2010 at 4:49 PM, James Robinson  wrote:

> There's a group at UC Berkeley that was (is?) working on a similar idea,
> you can read about it here:
> http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
>  With a
> discussion that happened a few months back here:
> http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.html
>
> From
> the discussion on webkit-dev I think the consensus was that it looked
> interesting but that it wasn't clear that any practical benefit to be gained
> in the short term.
>
> There's probably simpler parallelism problems in the Chromium codebase to
> tackle than those directly involving core layout and rendering code, perhaps
> some of the caching layers.
>
> - James
>
>
> On Thu, Jan 7, 2010 at 1:41 PM, Fady Samuel  wrote:
>
>> Well you can't know the precise set of locks you need obviously without
>> "solving the halting problem". But maybe a static analysis can give you a
>> conservative set of DOM trees you might access. Sorry, just thinking out
>> loud I guess.
>>
>> Fady
>>
>>
>> On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis  wrote:
>>
>>> The catch is that you don't know what locks you need to acquire in
>>> advance, especially in the presence of things like eval.  (And of course,
>>> you can't roll back any JavaScript you've already run, so you would need to
>>> know the locks in advance.)
>>>
>>> Charlie
>>>
>>>
>>> On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel wrote:
>>>
 Hmm, I wonder if strict two-phase locking can be here to solve this?

 Fady


>
> That's correct.  However, Fady is referring to an observation in my
> paper that race conditions are actually possible in cross-window 
> JavaScript
> calls in Internet Explorer and Opera.  Those browsers allow pages in
> different windows to run in separate threads, even if they are from the 
> same
> site and can easily call into each other.  From my tests, it appears that 
> IE
> at least tries to avoid race conditions by blocking one page until the 
> other
> finishes, but it allows the race if a deadlock occurs.
>
> You can test this fairly easily by calling a long-running function in
> another page that is repeatedly calling the function itself.  In Opera, 
> both
> pages' threads will be in the function at once.  In IE, the first page 
> will
> be blocked until the second finishes, unless the second page tries to call
> back into the first page at the end of its function.  That would be a
> deadlock, so instead they allow the data race.
>
> I don't think the spec allows for these races-- as people have
> mentioned, JavaScript has a single-threaded, run-to-completion model.
>  Chromium avoids races by only putting pages that can't communicate on
> different threads/processes.
>
> Charlie
>
>
>>>
>>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Peter Kasting]

On Thu, Jan 7, 2010 at 1:50 PM, Jeremy Orlow  wrote:

> What about renaming the function?  EmptyStringHACK() or something?


It's not a hack.  It's a perfectly legitimate thing to use, and not
something we're going to get rid of, unlike ToWStringHack().

Darin suggested we could make these return const pointers instead of const
refs, so callers would need to explicitly deref, to make things look uglier.
 I'm not a big fan of this.

If someone does misuse one of these, it won't corrupt memory, so it's not
catastrophe.  Removing all the wrong uses and adding clear comments about
the right uses, here and in the code, seems sufficient to me.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Jeremy Orlow]

What about renaming the function?  EmptyStringHACK() or something?

On Thu, Jan 7, 2010 at 1:49 PM, Peter Kasting  wrote:

> On Thu, Jan 7, 2010 at 1:43 PM, Jeremy Orlow  wrote:
>
>> You ignored the second half of my suggestion.
>>
>
> The second half of your suggestion leaks memory.  When we have easy and
> elegant ways to avoid memory leaks, it behooves us to use them.
>
> It also seems like a poor idea to me to suggest that, potentially, any
> function returning a string by reference might have to have its own memory
> leak, or allocation code, or static object, if it needs to be able to return
> an empty object.  Even if we could do that with no ill consequences, it
> would be nice to avoid it.
>
> After my patch, the total number of calls of these functions in the entire
> codebase is something like 10 instances.  They're rare enough to be
> invisible to most people and unusual otherwise.
>
> PK
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[James Robinson]

There's a group at UC Berkeley that was (is?) working on a similar idea, you
can read about it here:
http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
With a discussion
that happened a few months back here:
http://www.mail-archive.com/webkit-...@lists.webkit.org/msg07788.html

From
the discussion on webkit-dev I think the consensus was that it looked
interesting but that it wasn't clear that any practical benefit to be gained
in the short term.

There's probably simpler parallelism problems in the Chromium codebase to
tackle than those directly involving core layout and rendering code, perhaps
some of the caching layers.

- James

On Thu, Jan 7, 2010 at 1:41 PM, Fady Samuel  wrote:

> Well you can't know the precise set of locks you need obviously without
> "solving the halting problem". But maybe a static analysis can give you a
> conservative set of DOM trees you might access. Sorry, just thinking out
> loud I guess.
>
> Fady
>
>
> On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis  wrote:
>
>> The catch is that you don't know what locks you need to acquire in
>> advance, especially in the presence of things like eval.  (And of course,
>> you can't roll back any JavaScript you've already run, so you would need to
>> know the locks in advance.)
>>
>> Charlie
>>
>>
>> On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel  wrote:
>>
>>> Hmm, I wonder if strict two-phase locking can be here to solve this?
>>>
>>> Fady
>>>
>>>

 That's correct.  However, Fady is referring to an observation in my
 paper that race conditions are actually possible in cross-window JavaScript
 calls in Internet Explorer and Opera.  Those browsers allow pages in
 different windows to run in separate threads, even if they are from the 
 same
 site and can easily call into each other.  From my tests, it appears that 
 IE
 at least tries to avoid race conditions by blocking one page until the 
 other
 finishes, but it allows the race if a deadlock occurs.

 You can test this fairly easily by calling a long-running function in
 another page that is repeatedly calling the function itself.  In Opera, 
 both
 pages' threads will be in the function at once.  In IE, the first page will
 be blocked until the second finishes, unless the second page tries to call
 back into the first page at the end of its function.  That would be a
 deadlock, so instead they allow the data race.

 I don't think the spec allows for these races-- as people have
 mentioned, JavaScript has a single-threaded, run-to-completion model.
  Chromium avoids races by only putting pages that can't communicate on
 different threads/processes.

 Charlie


>>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Peter Kasting]

On Thu, Jan 7, 2010 at 1:43 PM, Jeremy Orlow  wrote:

> You ignored the second half of my suggestion.
>

The second half of your suggestion leaks memory.  When we have easy and
elegant ways to avoid memory leaks, it behooves us to use them.

It also seems like a poor idea to me to suggest that, potentially, any
function returning a string by reference might have to have its own memory
leak, or allocation code, or static object, if it needs to be able to return
an empty object.  Even if we could do that with no ill consequences, it
would be nice to avoid it.

After my patch, the total number of calls of these functions in the entire
codebase is something like 10 instances.  They're rare enough to be
invisible to most people and unusual otherwise.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Jeremy Orlow]

On Thu, Jan 7, 2010 at 1:38 PM, Peter Kasting  wrote:

> On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow  wrote:
>
>> (As discussed during lunch...)  Why not just do this in this case and
>> remove EmptyString() altogether?
>>
>> const std::string& MyClass::foo() const {
>>   static std::string empty = EmptyString();
>>   return (everything == OK) ? member_string : empty;
>> }
>>
>
> This is illegal per the Google style guide:
>
> "Objects with static storage duration, including ... function static
> variables, must be Plain Old Data (POD): only ints, chars, floats, or
> pointers, or arrays/structs of POD. ... This rule completely disallows
> vector (use C arrays instead), or string (use const char [])."
>
> If you see code like this in our codebase, please fix it to not use
> static/global non-POD types.
>

You ignored the second half of my suggestion.

IIRC there's a macro (maybe it was only in WebKit) to get around this issue
as well.

J


>
> PK
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Red Tree 2010/1/6

[Nicolas Sylvain]

On Thu, Jan 7, 2010 at 11:22 AM, James Robinson  wrote:

> Thanks a lot, Chase.
>
> When will it become feasible to run the perf tests as part of the WebKit
> canary process?  We seem to have all the code necessary to catch these
> regressions at the exact WebKit revision that causes them.
>

We've been doing that for months now.

Nicolas


>
> - James
>
> On Thu, Jan 7, 2010 at 11:13 AM, Chase Phillips wrote:
>
>> I'll take the bug for now to identify the WebKit rev that caused the
>> regression.
>>
>> On Wed, Jan 6, 2010 at 20:10, Robert Sesek  wrote:
>>
>>> Good evening,
>>>
>>> At 9pm ET, the tree was significantly red and Erik Kay closed the tree:
>>> Win browser_tests, Win & Mac perf, Linux views, and Win Webkit all were red.
>>> I cleaned up the Win browser_tests, Linux Views, and Win WebKit redness, but
>>> the Win & Mac perf regressions are still in play. mpcompete, jamesr, and I
>>> debated about what to do with this since it originated from a fairly
>>> significant WebKit roll:
>>> http://src.chromium.org/viewvc/chrome?view=rev&revision=35646. Backing
>>> out didn't seem like the best option because it was large jump and another
>>> roll happened later at r35669. The tree *is still closed* as of 11pm ET
>>> because http://crbug.com/31698 (tracking bug for this perf regression)
>>> does not yet have an owner and it desperately needs one! If in the morning
>>> someone more knowledgeable feels like we can open, please do.
>>>
>>> Also, I didn't have time to track it down tonight, but Windows UI
>>> Interactive (dbg) has been red on and off for the past couple of cycles,
>>> starting at
>>> http://build.chromium.org/buildbot/waterfall/builders/Interactive%20Tests%20(dbg)/builds/19501.
>>> I'm hesitant to mark it as flaky without knowing a little more, but I backed
>>> out oshima's change (the likely candidate) and the redness continued. Help
>>> appreciated :).
>>>
>>> Thanks and good night!
>>>
>>> rsesek / @chromium.org
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>>http://groups.google.com/group/chromium-dev
>>>
>>
>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Jeremy Orlow]

And before you suggest using software transactional memory, keep in mind
that side effects (XHRs and other network activity for example)
are prevalent in normal JavaScript usage.

I don't mean to discourage you too muchespecially if you were interested
in digging really deeply into this stuff...but I can assure you that a lot
of the more obvious, high level solutions to this stuff have been explored
many times over.  I think some of the more focused uses within specific
implementations might be a better place to start.

On Thu, Jan 7, 2010 at 1:36 PM, Charlie Reis  wrote:

> The catch is that you don't know what locks you need to acquire in advance,
> especially in the presence of things like eval.  (And of course, you can't
> roll back any JavaScript you've already run, so you would need to know the
> locks in advance.)
>
> Charlie
>
>
> On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel  wrote:
>
>> Hmm, I wonder if strict two-phase locking can be here to solve this?
>>
>> Fady
>>
>>
>>>
>>> That's correct.  However, Fady is referring to an observation in my paper
>>> that race conditions are actually possible in cross-window JavaScript calls
>>> in Internet Explorer and Opera.  Those browsers allow pages in different
>>> windows to run in separate threads, even if they are from the same site and
>>> can easily call into each other.  From my tests, it appears that IE at least
>>> tries to avoid race conditions by blocking one page until the other
>>> finishes, but it allows the race if a deadlock occurs.
>>>
>>> You can test this fairly easily by calling a long-running function in
>>> another page that is repeatedly calling the function itself.  In Opera, both
>>> pages' threads will be in the function at once.  In IE, the first page will
>>> be blocked until the second finishes, unless the second page tries to call
>>> back into the first page at the end of its function.  That would be a
>>> deadlock, so instead they allow the data race.
>>>
>>> I don't think the spec allows for these races-- as people have mentioned,
>>> JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
>>> races by only putting pages that can't communicate on different
>>> threads/processes.
>>>
>>> Charlie
>>>
>>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Fady Samuel]

Well you can't know the precise set of locks you need obviously without
"solving the halting problem". But maybe a static analysis can give you a
conservative set of DOM trees you might access. Sorry, just thinking out
loud I guess.

Fady

On Thu, Jan 7, 2010 at 4:36 PM, Charlie Reis  wrote:

> The catch is that you don't know what locks you need to acquire in advance,
> especially in the presence of things like eval.  (And of course, you can't
> roll back any JavaScript you've already run, so you would need to know the
> locks in advance.)
>
> Charlie
>
>
> On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel  wrote:
>
>> Hmm, I wonder if strict two-phase locking can be here to solve this?
>>
>> Fady
>>
>>
>>>
>>> That's correct.  However, Fady is referring to an observation in my paper
>>> that race conditions are actually possible in cross-window JavaScript calls
>>> in Internet Explorer and Opera.  Those browsers allow pages in different
>>> windows to run in separate threads, even if they are from the same site and
>>> can easily call into each other.  From my tests, it appears that IE at least
>>> tries to avoid race conditions by blocking one page until the other
>>> finishes, but it allows the race if a deadlock occurs.
>>>
>>> You can test this fairly easily by calling a long-running function in
>>> another page that is repeatedly calling the function itself.  In Opera, both
>>> pages' threads will be in the function at once.  In IE, the first page will
>>> be blocked until the second finishes, unless the second page tries to call
>>> back into the first page at the end of its function.  That would be a
>>> deadlock, so instead they allow the data race.
>>>
>>> I don't think the spec allows for these races-- as people have mentioned,
>>> JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
>>> races by only putting pages that can't communicate on different
>>> threads/processes.
>>>
>>> Charlie
>>>
>>>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Peter Kasting]

On Thu, Jan 7, 2010 at 1:34 PM, Jeremy Orlow  wrote:

> (As discussed during lunch...)  Why not just do this in this case and
> remove EmptyString() altogether?
>
> const std::string& MyClass::foo() const {
>   static std::string empty = EmptyString();
>   return (everything == OK) ? member_string : empty;
> }
>

This is illegal per the Google style guide:

"Objects with static storage duration, including ... function static
variables, must be Plain Old Data (POD): only ints, chars, floats, or
pointers, or arrays/structs of POD. ... This rule completely disallows
vector (use C arrays instead), or string (use const char [])."

If you see code like this in our codebase, please fix it to not use
static/global non-POD types.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Charlie Reis]

The catch is that you don't know what locks you need to acquire in advance,
especially in the presence of things like eval.  (And of course, you can't
roll back any JavaScript you've already run, so you would need to know the
locks in advance.)

Charlie


On Thu, Jan 7, 2010 at 1:35 PM, Fady Samuel  wrote:

> Hmm, I wonder if strict two-phase locking can be here to solve this?
>
> Fady
>
>
>>
>> That's correct.  However, Fady is referring to an observation in my paper
>> that race conditions are actually possible in cross-window JavaScript calls
>> in Internet Explorer and Opera.  Those browsers allow pages in different
>> windows to run in separate threads, even if they are from the same site and
>> can easily call into each other.  From my tests, it appears that IE at least
>> tries to avoid race conditions by blocking one page until the other
>> finishes, but it allows the race if a deadlock occurs.
>>
>> You can test this fairly easily by calling a long-running function in
>> another page that is repeatedly calling the function itself.  In Opera, both
>> pages' threads will be in the function at once.  In IE, the first page will
>> be blocked until the second finishes, unless the second page tries to call
>> back into the first page at the end of its function.  That would be a
>> deadlock, so instead they allow the data race.
>>
>> I don't think the spec allows for these races-- as people have mentioned,
>> JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
>> races by only putting pages that can't communicate on different
>> threads/processes.
>>
>> Charlie
>>
>>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Fady Samuel]

Hmm, I wonder if strict two-phase locking can be here to solve this?

Fady


>
> That's correct.  However, Fady is referring to an observation in my paper
> that race conditions are actually possible in cross-window JavaScript calls
> in Internet Explorer and Opera.  Those browsers allow pages in different
> windows to run in separate threads, even if they are from the same site and
> can easily call into each other.  From my tests, it appears that IE at least
> tries to avoid race conditions by blocking one page until the other
> finishes, but it allows the race if a deadlock occurs.
>
> You can test this fairly easily by calling a long-running function in
> another page that is repeatedly calling the function itself.  In Opera, both
> pages' threads will be in the function at once.  In IE, the first page will
> be blocked until the second finishes, unless the second page tries to call
> back into the first page at the end of its function.  That would be a
> deadlock, so instead they allow the data race.
>
> I don't think the spec allows for these races-- as people have mentioned,
> JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
> races by only putting pages that can't communicate on different
> threads/processes.
>
> Charlie
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Jeremy Orlow]

(As discussed during lunch...)  Why not just do this in this case and remove
EmptyString() altogether?

const std::string& MyClass::foo() const {
  static std::string empty = EmptyString();
  return (everything == OK) ? member_string : empty;
}

I forget if this runs the constructor on first use or when the app starts
up.  If it's the latter and you care, you can even just make it a null
pointer and allocate it on first use.

No matter what PSA or comments you write, someone will use it again if it's
there.

J

On Thu, Jan 7, 2010 at 1:28 PM, Peter Kasting  wrote:

> If you have ever used any of the EmptyXXX() functions, or ever will, please
> read on.
>
> These functions (in string_util.h and gurl.h) are meant for a single,
> specific use case:
>
> const std::string& MyClass::foo() const {
>   return (everything == OK) ? member_string : EmptyString();
> }
>
> Here you cannot return "string()", because it's destroyed before the
> function returns, and the caller receives garbage; and you don't want to
> have the function return by value, because you can access the member
> variable directly and save a copy.  The utility functions give you a global
> empty string that you can safely return a const reference to.
>
> DON'T USE THESE OUTSIDE THIS CASE.  You should never use these as
> initializers, arguments to functions, or return values in functions that
> return by value.  Just use the default constructor; that's what it's there
> for.
>
> I have a change out for review that removes the erroneous uses of these
> from our codebase and clarifies the comment on their declaration, but it's
> worth calling this out directly so they don't creep back in.
>
> PK
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Peter Kasting]

On Thu, Jan 7, 2010 at 1:30 PM, Fady Samuel  wrote:

> What about allowing the renderer to run asynchronously with the
> script?  Right now you're either producing the view or you're running script
> but never both concurrently, correct?  Parallelizing them should not
> introduce issues I think (assuming the renderer has the equivalent of a
> snapshot view of the DOM tree)?
>

But the chief use of JS is to manipulate the DOM.  There's little real
parallelism to extract there, and great cost to doing so.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Fady Samuel]

What about allowing the renderer to run asynchronously with the
script?  Right now you're either producing the view or you're running script
but never both concurrently, correct?  Parallelizing them should not
introduce issues I think (assuming the renderer has the equivalent of a
snapshot view of the DOM tree)?

Fady

On Thu, Jan 7, 2010 at 4:10 PM, Charlie Reis  wrote:

>
>
> On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie  wrote:
>
>>
>>
>> On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel  wrote:
>>
>>> Charles, I've read your paper and ultimately I think my goal may be
>>> somewhere along the lines of making the DOM tree thread-safe by applying my
>>> research in iterators and lock-free data structures.
>>>
>>>  A tricky question: What can be parallelized here? What level of
>>> atomicity is required by scripts.
>>>
>>> Does Javascript even provide a means to do any kind of concurrency
>>> control? Any locking mechanism? The paper suggests javascript knows nothing
>>> about multithreading (Disclaimer: I'm NOT a javascript expert).
>>>
>>> If not, what level of implicit atomicity does the browser need to provide
>>> for javascript? That is to say, can we allow two functions manipulating the
>>> same DOM interleave on a per statement basis? I'm  a bit worried that there
>>> are limitations in the language itself that make this problem extend beyond
>>> a consistent iteration problem.
>>>
>>> Do you have an example or two of race conditions you've seen in Internet
>>> Explorer? Heck, if you can provide me with javascript code samples that
>>> demonstrate issues so I can better understand what's going on that would be
>>> awesome.
>>>
>>
>> Javascript absolutely expects to be single-threaded, and Javascript
>> programmers expect it even more so.
>>
>>
>
> That's correct.  However, Fady is referring to an observation in my paper
> that race conditions are actually possible in cross-window JavaScript calls
> in Internet Explorer and Opera.  Those browsers allow pages in different
> windows to run in separate threads, even if they are from the same site and
> can easily call into each other.  From my tests, it appears that IE at least
> tries to avoid race conditions by blocking one page until the other
> finishes, but it allows the race if a deadlock occurs.
>
> You can test this fairly easily by calling a long-running function in
> another page that is repeatedly calling the function itself.  In Opera, both
> pages' threads will be in the function at once.  In IE, the first page will
> be blocked until the second finishes, unless the second page tries to call
> back into the first page at the end of its function.  That would be a
> deadlock, so instead they allow the data race.
>
> I don't think the spec allows for these races-- as people have mentioned,
> JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
> races by only putting pages that can't communicate on different
> threads/processes.
>
> Charlie
>
>
>
>>> Thanks,
>>>
>>> Fady
>>>
>>> On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis wrote:
>>>
 Peter's right: as far as I understand, parsing, rendering, and script
 execution are all expected to take place on a single thread of execution.
  This includes any calls across multiple pages, which is why we place
 "connected" same-site pages (those in the same unit of related browsing
 contexts) in the same process.  If one page calls a function in another
 page, we don't want to allow data races.

 For more info on the decisions we've made about which pages go to which
 process, see:
 http://dev.chromium.org/developers/design-documents/process-models

 We also have a Eurosys 2009 paper on the topic:
 http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf

 Hope that helps,
 Charlie


 On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting wrote:

> On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel wrote:
>
>> So a script cannot execute concurrently with the traversal of the DOM
>> tree? Could this be a performance bottleneck?
>
>
> Pretty much nothing in the renderer can execute concurrently with other
> things in the renderer.  There have been academic papers published about
> trying to parallelize parts of web rendering, and some though experiments
> from various smart Mozilla and WebKit folks, but from what I've seen it's
> not promising.  The web wasn't really designed with thread- or 
> process-level
> parallelism on the part of the UA in mind.  (Witness, for example, the
> horror of sync XHR, or how difficult it is to make alert()s not be
> renderer-modal.)
>
> In particular, it's fairly well-defined that script sees a coherent
> state as it executes, so unless you can solve the halting problem, there 
> are
> pretty severe limits on how much you could parallelize script execution 
> with
> other stuff.
>
> PK
>>>

[chromium-dev] Don't use Empty[String,WString,String16,GURL]() unless you really need to

[Peter Kasting]

If you have ever used any of the EmptyXXX() functions, or ever will, please
read on.

These functions (in string_util.h and gurl.h) are meant for a single,
specific use case:

const std::string& MyClass::foo() const {
  return (everything == OK) ? member_string : EmptyString();
}

Here you cannot return "string()", because it's destroyed before the
function returns, and the caller receives garbage; and you don't want to
have the function return by value, because you can access the member
variable directly and save a copy.  The utility functions give you a global
empty string that you can safely return a const reference to.

DON'T USE THESE OUTSIDE THIS CASE.  You should never use these as
initializers, arguments to functions, or return values in functions that
return by value.  Just use the default constructor; that's what it's there
for.

I have a change out for review that removes the erroneous uses of these from
our codebase and clarifies the comment on their declaration, but it's worth
calling this out directly so they don't creep back in.

PK
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Jeremy Orlow]

On Thu, Jan 7, 2010 at 1:10 PM, Charlie Reis  wrote:

>
>
> On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie  wrote:
>
>>
>>
>> On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel  wrote:
>>
>>> Charles, I've read your paper and ultimately I think my goal may be
>>> somewhere along the lines of making the DOM tree thread-safe by applying my
>>> research in iterators and lock-free data structures.
>>>
>>>  A tricky question: What can be parallelized here? What level of
>>> atomicity is required by scripts.
>>>
>>> Does Javascript even provide a means to do any kind of concurrency
>>> control? Any locking mechanism? The paper suggests javascript knows nothing
>>> about multithreading (Disclaimer: I'm NOT a javascript expert).
>>>
>>> If not, what level of implicit atomicity does the browser need to provide
>>> for javascript? That is to say, can we allow two functions manipulating the
>>> same DOM interleave on a per statement basis? I'm  a bit worried that there
>>> are limitations in the language itself that make this problem extend beyond
>>> a consistent iteration problem.
>>>
>>> Do you have an example or two of race conditions you've seen in Internet
>>> Explorer? Heck, if you can provide me with javascript code samples that
>>> demonstrate issues so I can better understand what's going on that would be
>>> awesome.
>>>
>>
>> Javascript absolutely expects to be single-threaded, and Javascript
>> programmers expect it even more so.
>>
>>
>
> That's correct.  However, Fady is referring to an observation in my paper
> that race conditions are actually possible in cross-window JavaScript calls
> in Internet Explorer and Opera.  Those browsers allow pages in different
> windows to run in separate threads, even if they are from the same site and
> can easily call into each other.  From my tests, it appears that IE at least
> tries to avoid race conditions by blocking one page until the other
> finishes, but it allows the race if a deadlock occurs.
>
> You can test this fairly easily by calling a long-running function in
> another page that is repeatedly calling the function itself.  In Opera, both
> pages' threads will be in the function at once.  In IE, the first page will
> be blocked until the second finishes, unless the second page tries to call
> back into the first page at the end of its function.  That would be a
> deadlock, so instead they allow the data race.
>
> I don't think the spec allows for these races-- as people have mentioned,
> JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
> races by only putting pages that can't communicate on different
> threads/processes.
>

There are 2 exceptions in Chrome and IE (and maybe Opera?): Cookies and
LocalStorage.

The spec attempts to solve both of these with a "Storage Mutex" which
basically must be taken on the first access to a cookie or localStorage and
must not be released until the current script execution ends.  The network
stack is also supposed to take this lock when reading or writing cookies.
 The single mutex is shared across the entire browser.

A LOT of time and effort has been spent on coming up with a better answer,
but there are a lot of constraints to the problem (not all of them
technical) and I've pretty much given up hope of anything better replacing
it in the spec.

That said, we have no intention of being the first to implement the storage
mutex in Chrome, and I know of no one else intending to implement it either.
 So until then, cookie and localStorage access is simply racy (in Chrome,
IE, and maybe Opera).

Charlie
>
>
>
>>> Thanks,
>>>
>>> Fady
>>>
>>> On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis wrote:
>>>
 Peter's right: as far as I understand, parsing, rendering, and script
 execution are all expected to take place on a single thread of execution.
  This includes any calls across multiple pages, which is why we place
 "connected" same-site pages (those in the same unit of related browsing
 contexts) in the same process.  If one page calls a function in another
 page, we don't want to allow data races.

 For more info on the decisions we've made about which pages go to which
 process, see:
 http://dev.chromium.org/developers/design-documents/process-models

 We also have a Eurosys 2009 paper on the topic:
 http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf

 Hope that helps,
 Charlie


 On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting wrote:

> On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel wrote:
>
>> So a script cannot execute concurrently with the traversal of the DOM
>> tree? Could this be a performance bottleneck?
>
>
> Pretty much nothing in the renderer can execute concurrently with other
> things in the renderer.  There have been academic papers published about
> trying to parallelize parts of web rendering, and some though experiments
> from various smart Mozilla and Web

Re: [chromium-dev] Replicated State among tabs in Chromium

[Charlie Reis]

On Thu, Jan 7, 2010 at 12:53 PM, Ben Laurie  wrote:

>
>
> On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel  wrote:
>
>> Charles, I've read your paper and ultimately I think my goal may be
>> somewhere along the lines of making the DOM tree thread-safe by applying my
>> research in iterators and lock-free data structures.
>>
>>  A tricky question: What can be parallelized here? What level of atomicity
>> is required by scripts.
>>
>> Does Javascript even provide a means to do any kind of concurrency
>> control? Any locking mechanism? The paper suggests javascript knows nothing
>> about multithreading (Disclaimer: I'm NOT a javascript expert).
>>
>> If not, what level of implicit atomicity does the browser need to provide
>> for javascript? That is to say, can we allow two functions manipulating the
>> same DOM interleave on a per statement basis? I'm  a bit worried that there
>> are limitations in the language itself that make this problem extend beyond
>> a consistent iteration problem.
>>
>> Do you have an example or two of race conditions you've seen in Internet
>> Explorer? Heck, if you can provide me with javascript code samples that
>> demonstrate issues so I can better understand what's going on that would be
>> awesome.
>>
>
> Javascript absolutely expects to be single-threaded, and Javascript
> programmers expect it even more so.
>
>

That's correct.  However, Fady is referring to an observation in my paper
that race conditions are actually possible in cross-window JavaScript calls
in Internet Explorer and Opera.  Those browsers allow pages in different
windows to run in separate threads, even if they are from the same site and
can easily call into each other.  From my tests, it appears that IE at least
tries to avoid race conditions by blocking one page until the other
finishes, but it allows the race if a deadlock occurs.

You can test this fairly easily by calling a long-running function in
another page that is repeatedly calling the function itself.  In Opera, both
pages' threads will be in the function at once.  In IE, the first page will
be blocked until the second finishes, unless the second page tries to call
back into the first page at the end of its function.  That would be a
deadlock, so instead they allow the data race.

I don't think the spec allows for these races-- as people have mentioned,
JavaScript has a single-threaded, run-to-completion model.  Chromium avoids
races by only putting pages that can't communicate on different
threads/processes.

Charlie



>> Thanks,
>>
>> Fady
>>
>> On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis  wrote:
>>
>>> Peter's right: as far as I understand, parsing, rendering, and script
>>> execution are all expected to take place on a single thread of execution.
>>>  This includes any calls across multiple pages, which is why we place
>>> "connected" same-site pages (those in the same unit of related browsing
>>> contexts) in the same process.  If one page calls a function in another
>>> page, we don't want to allow data races.
>>>
>>> For more info on the decisions we've made about which pages go to which
>>> process, see:
>>> http://dev.chromium.org/developers/design-documents/process-models
>>>
>>> We also have a Eurosys 2009 paper on the topic:
>>> http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf
>>>
>>> Hope that helps,
>>> Charlie
>>>
>>>
>>> On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting wrote:
>>>
 On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel wrote:

> So a script cannot execute concurrently with the traversal of the DOM
> tree? Could this be a performance bottleneck?


 Pretty much nothing in the renderer can execute concurrently with other
 things in the renderer.  There have been academic papers published about
 trying to parallelize parts of web rendering, and some though experiments
 from various smart Mozilla and WebKit folks, but from what I've seen it's
 not promising.  The web wasn't really designed with thread- or 
 process-level
 parallelism on the part of the UA in mind.  (Witness, for example, the
 horror of sync XHR, or how difficult it is to make alert()s not be
 renderer-modal.)

 In particular, it's fairly well-defined that script sees a coherent
 state as it executes, so unless you can solve the halting problem, there 
 are
 pretty severe limits on how much you could parallelize script execution 
 with
 other stuff.

 PK

 --
 Chromium Developers mailing list: chromium-dev@googlegroups.com
 View archives, change email options, or unsubscribe:
 http://groups.google.com/group/chromium-dev

>>>
>>>
>>
>> --
>>
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsub

Re: [chromium-dev] Replicated State among tabs in Chromium

[Ben Laurie]

On Thu, Jan 7, 2010 at 8:43 PM, Fady Samuel  wrote:

> Charles, I've read your paper and ultimately I think my goal may be
> somewhere along the lines of making the DOM tree thread-safe by applying my
> research in iterators and lock-free data structures.
>
>  A tricky question: What can be parallelized here? What level of atomicity
> is required by scripts.
>
> Does Javascript even provide a means to do any kind of concurrency control?
> Any locking mechanism? The paper suggests javascript knows nothing about
> multithreading (Disclaimer: I'm NOT a javascript expert).
>
> If not, what level of implicit atomicity does the browser need to provide
> for javascript? That is to say, can we allow two functions manipulating the
> same DOM interleave on a per statement basis? I'm  a bit worried that there
> are limitations in the language itself that make this problem extend beyond
> a consistent iteration problem.
>
> Do you have an example or two of race conditions you've seen in Internet
> Explorer? Heck, if you can provide me with javascript code samples that
> demonstrate issues so I can better understand what's going on that would be
> awesome.
>

Javascript absolutely expects to be single-threaded, and Javascript
programmers expect it even more so.


>
> Thanks,
>
> Fady
>
> On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis  wrote:
>
>> Peter's right: as far as I understand, parsing, rendering, and script
>> execution are all expected to take place on a single thread of execution.
>>  This includes any calls across multiple pages, which is why we place
>> "connected" same-site pages (those in the same unit of related browsing
>> contexts) in the same process.  If one page calls a function in another
>> page, we don't want to allow data races.
>>
>> For more info on the decisions we've made about which pages go to which
>> process, see:
>> http://dev.chromium.org/developers/design-documents/process-models
>>
>> We also have a Eurosys 2009 paper on the topic:
>> http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf
>>
>> Hope that helps,
>> Charlie
>>
>>
>> On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting wrote:
>>
>>> On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel wrote:
>>>
 So a script cannot execute concurrently with the traversal of the DOM
 tree? Could this be a performance bottleneck?
>>>
>>>
>>> Pretty much nothing in the renderer can execute concurrently with other
>>> things in the renderer.  There have been academic papers published about
>>> trying to parallelize parts of web rendering, and some though experiments
>>> from various smart Mozilla and WebKit folks, but from what I've seen it's
>>> not promising.  The web wasn't really designed with thread- or process-level
>>> parallelism on the part of the UA in mind.  (Witness, for example, the
>>> horror of sync XHR, or how difficult it is to make alert()s not be
>>> renderer-modal.)
>>>
>>> In particular, it's fairly well-defined that script sees a coherent state
>>> as it executes, so unless you can solve the halting problem, there are
>>> pretty severe limits on how much you could parallelize script execution with
>>> other stuff.
>>>
>>> PK
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>>
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[James Robinson]

On Thu, Jan 7, 2010 at 12:43 PM, Fady Samuel  wrote:

> Charles, I've read your paper and ultimately I think my goal may be
> somewhere along the lines of making the DOM tree thread-safe by applying my
> research in iterators and lock-free data structures.
>
>  A tricky question: What can be parallelized here? What level of atomicity
> is required by scripts.
>
> Does Javascript even provide a means to do any kind of concurrency control?
> Any locking mechanism? The paper suggests javascript knows nothing about
> multithreading (Disclaimer: I'm NOT a javascript expert).
>

That's correct - there is no notion of multithreading or concurrency in the
JavaScript language, and no locking primitives.


>
> If not, what level of implicit atomicity does the browser need to provide
> for javascript? That is to say, can we allow two functions manipulating the
> same DOM interleave on a per statement basis? I'm  a bit worried that there
> are limitations in the language itself that make this problem extend beyond
> a consistent iteration problem.
>

No, you can't interleave execution between different pieces of JavaScript in
the same context at all (at least, you can't let any JavaScript observe that
you are doing so - and since so much JavaScript touches the global object
this boils down to the same thing).  JavaScript has a fairly simple
run-to-completion model.

- James


> Do you have an example or two of race conditions you've seen in Internet
> Explorer? Heck, if you can provide me with javascript code samples that
> demonstrate issues so I can better understand what's going on that would be
> awesome.
>
> Thanks,
>
> Fady
>
> On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis  wrote:
>
>> Peter's right: as far as I understand, parsing, rendering, and script
>> execution are all expected to take place on a single thread of execution.
>>  This includes any calls across multiple pages, which is why we place
>> "connected" same-site pages (those in the same unit of related browsing
>> contexts) in the same process.  If one page calls a function in another
>> page, we don't want to allow data races.
>>
>> For more info on the decisions we've made about which pages go to which
>> process, see:
>> http://dev.chromium.org/developers/design-documents/process-models
>>
>> We also have a Eurosys 2009 paper on the topic:
>> http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf
>>
>> Hope that helps,
>> Charlie
>>
>>
>> On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting wrote:
>>
>>> On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel wrote:
>>>
 So a script cannot execute concurrently with the traversal of the DOM
 tree? Could this be a performance bottleneck?
>>>
>>>
>>> Pretty much nothing in the renderer can execute concurrently with other
>>> things in the renderer.  There have been academic papers published about
>>> trying to parallelize parts of web rendering, and some though experiments
>>> from various smart Mozilla and WebKit folks, but from what I've seen it's
>>> not promising.  The web wasn't really designed with thread- or process-level
>>> parallelism on the part of the UA in mind.  (Witness, for example, the
>>> horror of sync XHR, or how difficult it is to make alert()s not be
>>> renderer-modal.)
>>>
>>> In particular, it's fairly well-defined that script sees a coherent state
>>> as it executes, so unless you can solve the halting problem, there are
>>> pretty severe limits on how much you could parallelize script execution with
>>> other stuff.
>>>
>>> PK
>>>
>>> --
>>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/group/chromium-dev
>>>
>>
>>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Replicated State among tabs in Chromium

[Fady Samuel]

Charles, I've read your paper and ultimately I think my goal may be
somewhere along the lines of making the DOM tree thread-safe by applying my
research in iterators and lock-free data structures.

 A tricky question: What can be parallelized here? What level of atomicity
is required by scripts.

Does Javascript even provide a means to do any kind of concurrency control?
Any locking mechanism? The paper suggests javascript knows nothing about
multithreading (Disclaimer: I'm NOT a javascript expert).

If not, what level of implicit atomicity does the browser need to provide
for javascript? That is to say, can we allow two functions manipulating the
same DOM interleave on a per statement basis? I'm  a bit worried that there
are limitations in the language itself that make this problem extend beyond
a consistent iteration problem.

Do you have an example or two of race conditions you've seen in Internet
Explorer? Heck, if you can provide me with javascript code samples that
demonstrate issues so I can better understand what's going on that would be
awesome.

Thanks,

Fady

On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis  wrote:

> Peter's right: as far as I understand, parsing, rendering, and script
> execution are all expected to take place on a single thread of execution.
>  This includes any calls across multiple pages, which is why we place
> "connected" same-site pages (those in the same unit of related browsing
> contexts) in the same process.  If one page calls a function in another
> page, we don't want to allow data races.
>
> For more info on the decisions we've made about which pages go to which
> process, see:
> http://dev.chromium.org/developers/design-documents/process-models
>
> We also have a Eurosys 2009 paper on the topic:
> http://www.cs.washington.edu/homes/creis/publications/eurosys-2009.pdf
>
> Hope that helps,
> Charlie
>
>
> On Mon, Jan 4, 2010 at 7:10 PM, Peter Kasting  wrote:
>
>> On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel  wrote:
>>
>>> So a script cannot execute concurrently with the traversal of the DOM
>>> tree? Could this be a performance bottleneck?
>>
>>
>> Pretty much nothing in the renderer can execute concurrently with other
>> things in the renderer.  There have been academic papers published about
>> trying to parallelize parts of web rendering, and some though experiments
>> from various smart Mozilla and WebKit folks, but from what I've seen it's
>> not promising.  The web wasn't really designed with thread- or process-level
>> parallelism on the part of the UA in mind.  (Witness, for example, the
>> horror of sync XHR, or how difficult it is to make alert()s not be
>> renderer-modal.)
>>
>> In particular, it's fairly well-defined that script sees a coherent state
>> as it executes, so unless you can solve the halting problem, there are
>> pretty severe limits on how much you could parallelize script execution with
>> other stuff.
>>
>> PK
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Red Tree 2010/1/6

[James Robinson]

Thanks a lot, Chase.

When will it become feasible to run the perf tests as part of the WebKit
canary process?  We seem to have all the code necessary to catch these
regressions at the exact WebKit revision that causes them.

- James

On Thu, Jan 7, 2010 at 11:13 AM, Chase Phillips  wrote:

> I'll take the bug for now to identify the WebKit rev that caused the
> regression.
>
> On Wed, Jan 6, 2010 at 20:10, Robert Sesek  wrote:
>
>> Good evening,
>>
>> At 9pm ET, the tree was significantly red and Erik Kay closed the tree:
>> Win browser_tests, Win & Mac perf, Linux views, and Win Webkit all were red.
>> I cleaned up the Win browser_tests, Linux Views, and Win WebKit redness, but
>> the Win & Mac perf regressions are still in play. mpcompete, jamesr, and I
>> debated about what to do with this since it originated from a fairly
>> significant WebKit roll:
>> http://src.chromium.org/viewvc/chrome?view=rev&revision=35646. Backing
>> out didn't seem like the best option because it was large jump and another
>> roll happened later at r35669. The tree *is still closed* as of 11pm ET
>> because http://crbug.com/31698 (tracking bug for this perf regression)
>> does not yet have an owner and it desperately needs one! If in the morning
>> someone more knowledgeable feels like we can open, please do.
>>
>> Also, I didn't have time to track it down tonight, but Windows UI
>> Interactive (dbg) has been red on and off for the past couple of cycles,
>> starting at
>> http://build.chromium.org/buildbot/waterfall/builders/Interactive%20Tests%20(dbg)/builds/19501.
>> I'm hesitant to mark it as flaky without knowing a little more, but I backed
>> out oshima's change (the likely candidate) and the redness continued. Help
>> appreciated :).
>>
>> Thanks and good night!
>>
>> rsesek / @chromium.org
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>>http://groups.google.com/group/chromium-dev
>>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Linux Perf, revision 35707

[buildbot]

Automatically closing tree for "compile" on "Linux Perf"

http://build.chromium.org/buildbot/waterfall/builders/Linux%20Perf/builds/4822

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Linux%20Perf

--=>  Automatically closing tree for "compile" on "Linux Perf"  <=--

Revision: 35706, 35707
Blame list: stuartmor...@chromium.org,t...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?

[Darin Fisher]

It could... but, I though the conclusion was to avoid DOM UI for file:// and
ftp:// directory listings (for other reasons).  In that case, we should be
able to continue using the same UI.  I think there is just the open question
of how to provide icon resources to the page.

-Darin


On Thu, Jan 7, 2010 at 4:11 AM, Dean McNamee  wrote:

> Yeah, so my question was, does that mean test_shell would have a
> separate mechanism (the current one?) for file:/// listings?
>
> On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher  wrote:
> > DOM UI implies chrome://, which is implemented by the
> ChromeURLDataManager
> > (in browser/dom_ui/).  TestShell wouldn't be able to use that.
> > -Darin
> >
> > On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee  wrote:
> >>
> >> I am pretty out of things these days, but will a DOM UI file://
> >> listing work for test_shell?
> >>
> >> On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher 
> wrote:
> >> > Right, that's the tricky part.  You'd need to do something creative.
> >> > -Darin
> >> >
> >> > On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette
> >> >  wrote:
> >> >>
> >> >> Okay. Yes we could use data URI, but where do we retrieve the icon
> >> >> resources from at that level?
> >> >>
> >> >> 2010/1/6 Darin Fisher 
> >> >>>
> >> >>> We can also use data: URLs to inject the icons into the HTML file
> used
> >> >>> to
> >> >>> render the directory listings.  We can do that at the time when the
> >> >>> HTML
> >> >>> file is generated.
> >> >>> -Darin
> >> >>>
> >> >>>
> >> >>> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin 
> wrote:
> >> 
> >>  I talked with Arv in person and I think I sufficiently convinced
> him
> >>  that getting DOMUI security right is tricky.  (Consider: XSSes in
> the
> >>  FTP display code, and that ftp sites containing HTML pages must not
> >>  have privs when displaying the HTML.)  That may still mean that
> DOMUI
> >>  is ok, but I would prefer to consider any other option available.
> >> 
> >>  One idea is to say "we don't care if any old page can  >>  src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
> >>  Not sure.
> >> 
> >>  On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson 
> >>  wrote:
> >>  > I think it should be OK to move these to DOMUI. NTP can also link
> >>  > to
> >>  > local HTML files and we already mark the chrome protocol in such
> a
> >>  > way
> >>  > that it cannot be accessed by any other scheme.
> >>  >
> >>  > erik
> >>  >
> >>  >
> >>  >
> >>  > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
> >>  >  wrote:
> >>  >> That's why I wanted to check before starting any work. So the
> >>  >> question is
> >>  >> now whether it we'd rather use a DOM UI page or create a similar
> >>  >> API
> >>  >> that
> >>  >> would be used solely by file:// and ftp://. What is needed for
> >>  >> http://crbug.com/24421 is simply access to the favicon data for
> >>  >> file
> >>  >> types.
> >>  >> I'm not sure if these are available through WebCore or not. The
> >>  >> drag
> >>  >> and
> >>  >> drop functionality required by http://crbug.com/27772 seems
> like
> >>  >> it
> >>  >> would be
> >>  >> a lot of work without using a DOM UI page.
> >>  >> Any opinions on this part of my original post?:
> >>  >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui
> >>  >> page
> >>  >> couldn't
> >>  >> be generalized to
> >>  >> be used for these other directory listing pages?
> >>  >> It just seems to me that it would be rather redundant handle 3
> >>  >> separate
> >>  >> instances of a file browse HTML page (ftp://, file:// and
> >>  >> chrome://filebrowse) in 3 separate ways.
> >>  >> Thanks.
> >>  >> 2010/1/5 Evan Martin 
> >>  >>>
> >>  >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy  >
> >>  >>> wrote:
> >>  >>> > I don't think anyone has any objection to DOMUIifying those
> >>  >>> > pages,
> >>  >>> > and
> >>  >>> > I don't think it would be a large amount of work. The only
> >>  >>> > reason
> >>  >>> > they're not is that there hasn't been a reason to do so.
> >>  >>>
> >>  >>> DOM UI (at least when I last looked) just means that that
> >>  >>> renderer
> >>  >>> ("the page") gets extra privileges necessary for doing special
> >>  >>> browser
> >>  >>> calls, such as access to your browsing history for the History
> >>  >>> implementation.
> >>  >>>
> >>  >>> We went to some effort to keep these sorts of pages distinct
> from
> >>  >>> network content with the hope of reducing the security surface.
> >>  >>>  I
> >>  >>> worry changing this for FTP would be going in the wrong
> >>  >>> direction.
> >>  >>>
> >>  >>> It might make more sense to do something *like* DOM UI but with
> a
> >>  >>> different API just to k

Re: [chromium-dev] Can we use a DOM ui page for ftp:/// and file:/// directory listings?

[Dean McNamee]

Yeah, so my question was, does that mean test_shell would have a
separate mechanism (the current one?) for file:/// listings?

On Thu, Jan 7, 2010 at 8:47 AM, Darin Fisher  wrote:
> DOM UI implies chrome://, which is implemented by the ChromeURLDataManager
> (in browser/dom_ui/).  TestShell wouldn't be able to use that.
> -Darin
>
> On Wed, Jan 6, 2010 at 1:43 PM, Dean McNamee  wrote:
>>
>> I am pretty out of things these days, but will a DOM UI file://
>> listing work for test_shell?
>>
>> On Wed, Jan 6, 2010 at 8:29 PM, Darin Fisher  wrote:
>> > Right, that's the tricky part.  You'd need to do something creative.
>> > -Darin
>> >
>> > On Wed, Jan 6, 2010 at 7:59 AM, Pierre-Antoine LaFayette
>> >  wrote:
>> >>
>> >> Okay. Yes we could use data URI, but where do we retrieve the icon
>> >> resources from at that level?
>> >>
>> >> 2010/1/6 Darin Fisher 
>> >>>
>> >>> We can also use data: URLs to inject the icons into the HTML file used
>> >>> to
>> >>> render the directory listings.  We can do that at the time when the
>> >>> HTML
>> >>> file is generated.
>> >>> -Darin
>> >>>
>> >>>
>> >>> On Tue, Jan 5, 2010 at 4:16 PM, Evan Martin  wrote:
>> 
>>  I talked with Arv in person and I think I sufficiently convinced him
>>  that getting DOMUI security right is tricky.  (Consider: XSSes in the
>>  FTP display code, and that ftp sites containing HTML pages must not
>>  have privs when displaying the HTML.)  That may still mean that DOMUI
>>  is ok, but I would prefer to consider any other option available.
>> 
>>  One idea is to say "we don't care if any old page can >  src='chrome://os-style-icon/foobar.psd'>" to get a Photoshop icon.
>>  Not sure.
>> 
>>  On Tue, Jan 5, 2010 at 3:33 PM, Erik Arvidsson 
>>  wrote:
>>  > I think it should be OK to move these to DOMUI. NTP can also link
>>  > to
>>  > local HTML files and we already mark the chrome protocol in such a
>>  > way
>>  > that it cannot be accessed by any other scheme.
>>  >
>>  > erik
>>  >
>>  >
>>  >
>>  > On Tue, Jan 5, 2010 at 15:19, Pierre-Antoine LaFayette
>>  >  wrote:
>>  >> That's why I wanted to check before starting any work. So the
>>  >> question is
>>  >> now whether it we'd rather use a DOM UI page or create a similar
>>  >> API
>>  >> that
>>  >> would be used solely by file:// and ftp://. What is needed for
>>  >> http://crbug.com/24421 is simply access to the favicon data for
>>  >> file
>>  >> types.
>>  >> I'm not sure if these are available through WebCore or not. The
>>  >> drag
>>  >> and
>>  >> drop functionality required by http://crbug.com/27772 seems like
>>  >> it
>>  >> would be
>>  >> a lot of work without using a DOM UI page.
>>  >> Any opinions on this part of my original post?:
>>  >> Is there any reason why ChromiumOS' chrome://filebrowse DOM ui
>>  >> page
>>  >> couldn't
>>  >> be generalized to
>>  >> be used for these other directory listing pages?
>>  >> It just seems to me that it would be rather redundant handle 3
>>  >> separate
>>  >> instances of a file browse HTML page (ftp://, file:// and
>>  >> chrome://filebrowse) in 3 separate ways.
>>  >> Thanks.
>>  >> 2010/1/5 Evan Martin 
>>  >>>
>>  >>> On Tue, Jan 5, 2010 at 2:44 PM, Glen Murphy 
>>  >>> wrote:
>>  >>> > I don't think anyone has any objection to DOMUIifying those
>>  >>> > pages,
>>  >>> > and
>>  >>> > I don't think it would be a large amount of work. The only
>>  >>> > reason
>>  >>> > they're not is that there hasn't been a reason to do so.
>>  >>>
>>  >>> DOM UI (at least when I last looked) just means that that
>>  >>> renderer
>>  >>> ("the page") gets extra privileges necessary for doing special
>>  >>> browser
>>  >>> calls, such as access to your browsing history for the History
>>  >>> implementation.
>>  >>>
>>  >>> We went to some effort to keep these sorts of pages distinct from
>>  >>> network content with the hope of reducing the security surface.
>>  >>>  I
>>  >>> worry changing this for FTP would be going in the wrong
>>  >>> direction.
>>  >>>
>>  >>> It might make more sense to do something *like* DOM UI but with a
>>  >>> different API just to keep things distinct.  But then we
>>  >>> reencounter
>>  >>> the same sorts of problems we have with DOM UI, like for example
>>  >>> if
>>  >>> you click a link from an FTP site to an HTML file, how to prevent
>>  >>> the
>>  >>> FTP privileges from bleeding into the HTML file.
>>  >>>
>>  >>> I feel like Darin is the person who would best know how to
>>  >>> address
>>  >>> this.
>>  >>>  :)
>>  >>
>>  >>
>>  >>
>>  >> --
>>  >> Pierre.
>>  >>
>>  >> --
>>  >> Chromium Developers mailing list: chromium

[chromium-dev] Re: buildbot failure in Chromium on Webkit (dbg)(1), revision 35699

[Craig Schlenter]

Random hang unrelated to my change AFAICS ... looks like it's going green on
the next build.

--Craig


On Thu, Jan 7, 2010 at 12:55 PM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "test_shell_tests" on "Webkit (dbg)(1)"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Webkit%20%28dbg%29%281%29/builds/14333
>
> Revision: 35699
> Blame list: craig.schlen...@chromium.org
>
>  Webkit (dbg)(1)
> Build 
> 14333
> svnkill
> stdio
>   update
> scripts
> stdio
> taskkill
> stdio
> update
> stdio
>   extract
> build
> stdio
> test_shell_tests
> did not complete
> crashed or hung
> stdio
>
> Changed by: *craig.schlen...@chromium.org*
> Changed at: *Thu 07 Jan 2010 02:39:34*
> Branch: *src*
> Revision: 
> *35699*
> Changed files:
>
>- *chrome/common/extensions/update_manifest.cc*
>
> Comments:
>
> Add some missing va_end calls to match va_start.
>
> BUG=31085
>
> Review URL: http://codereview.chromium.org/525073
>
> Properties:
>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] buildbot failure in Chromium on Webkit (dbg)(1), revision 35699

[buildbot]

Automatically closing tree for "test_shell_tests" on "Webkit (dbg)(1)"

http://build.chromium.org/buildbot/waterfall/builders/Webkit%20%28dbg%29%281%29/builds/14333

http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20%28dbg%29%281%29

--=>  Automatically closing tree for "test_shell_tests" on "Webkit (dbg)(1)"  
<=--

Revision: 35699
Blame list: craig.schlen...@chromium.org

Buildbot waterfall: http://build.chromium.org/
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev