Traceline is a good way to see how this happens. We generally name
all of the Chrome threads (base::Thread), but the system is allowed to
create threads of its own. Loads of APIs create threads, along with
the windows worker pool (which we make good use of to help reuse
threads). For example,
FYI, the symbols were added on Dec 30.
http://build.chromium.org/buildbot/symbols/3.0.195.38/chrome_dll.pdb
http://build.chromium.org/buildbot/symsrv/chrome_dll.pdb/A94BABB37F7A4445A7A2C7BC2B796FD81/chrome_dll.pdb
M-A
On Tue, Dec 29, 2009 at 10:14 PM, yuhong yuhongbao_...@hotmail.com wrote:
Are these numbers generated by running all tests, eg unit, ui,
browser, interactive .. ?
-Scott
On Thu, Dec 31, 2009 at 9:07 PM, John Grabowski j...@chromium.org wrote:
I had an OKR to get code coverage working on 3 platforms for Chromium unit
test bundles in Q409.
If you're in PST, I made
Hello,
I am a student of computer science and want to implement a jail for
java-script or at least gather some information how one could do
that.
The idea is not new. Brandon Eich had it before.
So the idea is to tell the browser: do not execute java-script within
this area, although the domain
At this time, just the tests which run successfully on all 3 platforms. The
list from chrome_tests.gypi:
'automated_ui_tests',
'../app/app.gyp:app_unittests',
'../base/base.gyp:base_unittests',
'../ipc/ipc.gyp:ipc_tests',
You are looking at older data. Look at numbers from Dec31 or later. I
wasn't exaggerating when I said just barely got three platforms working in
Q409.
The low linux number problem was caused by a switch from scons to make as
the default builder on all bots a few weeks ago. There were a number
On Mon, Jan 4, 2010 at 6:09 AM, Mathias Wagner wolfsb...@googlemail.com wrote:
Hello,
I am a student of computer science and want to implement a jail for
java-script or at least gather some information how one could do
that.
The idea is not new. Brandon Eich had it before.
So the idea is to
Hi Mathias. Thanks for your interest. See below:
On Mon, Jan 4, 2010 at 6:09 AM, Mathias Wagner wolfsb...@googlemail.com wrote:
1. Are there any plans of implementing stuff like this in Google
Chrome or WebKit in general? Please note that there is a difference
compared to the approach of
See the ClickAppModalDialogButton automation IPC message (implementation is
in chrome/browser/automation_provider.cc). I don't see any specifically
testing just that message, and I don't see any in-process browser tests
covering javascript alerts. Creating
On Thu, Dec 31, 2009 at 7:24 PM, n179911 n179...@gmail.com wrote:
On Thu, Dec 31, 2009 at 3:17 PM, Dan Kegel d...@kegel.com wrote:
On Thu, Dec 31, 2009 at 3:14 PM, n179911 n179...@gmail.com wrote:
And I have put 'shared' library in my include gypi file
$ more ~/.gyp/include.gpyi
There's also a few in-process browser tests in
chrome/browser/browser_browsertest.cc that call alert and dismiss the dialog
as part of testing something else, though they don't explicitly test aspects
of alert's behavior. Just search for alert in that file to see how to
use
Automatically closing tree for compile on Chromium Arm
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Arm/builds/392
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20Arm
--= Automatically closing tree for compile on Chromium Arm =--
Revision: 35481,
Just for the record - Tp prefix stands for Thread Pool, and Tpp
for Thread Pool Private (function).
So yes, these are threads created by the system.
On Thu, Dec 31, 2009 at 10:09 AM, Jim Roskind j...@chromium.org wrote:
I'm pretty sure we name all the threads we can (or at least used to), I
Hi:
I build a Release chromium from latest trunk code.my Chromium always
crash when page
contain flash elements.
on ubuntu 9.10
intel 32
build command
make BUILDTYPE=Release
and make chrome BUILDTYPE=Release
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
Good to see this.
I don't see a reference to layout tests. Given that webkit is listed at 9%
coverage, I'd guess that these aren't running either.
Erik
On Mon, Jan 4, 2010 at 10:00 AM, John Grabowski j...@chromium.org wrote:
At this time, just the tests which run successfully on all 3
You are correct; I am not running layout tests on the coverage bots.
Definitely something else to work on.
jrg
On Mon, Jan 4, 2010 at 3:46 PM, Erik Kay erik...@chromium.org wrote:
Good to see this.
I don't see a reference to layout tests. Given that webkit is listed at 9%
coverage, I'd
On Mon, Jan 4, 2010 at 3:38 PM, Peter Kasting pkast...@google.com wrote:
On Mon, Jan 4, 2010 at 3:35 PM, if-ifone hello...@gmail.com wrote:
Hi:
I build a Release chromium from latest trunk code.my Chromium always
crash when page
contain flash elements.
on ubuntu 9.10
intel 32
build
Hello all,
I'm interested in looking into replicated state between processes in
Chromium to try to share more of that state and help reduce Chromium's
memory footprint. I am unfamiliar with the Chromium source at this
point in time, so I would appreciate if someone would point me to the
problem
There are some caches in webkit (the resource cache in particular, but there
are others) that would be nice to share between processes.
-Darin
On Mon, Jan 4, 2010 at 4:43 PM, Fady Samuel fadysam...@gmail.com wrote:
Hello all,
I'm interested in looking into replicated state between processes
On Mon, Jan 4, 2010 at 4:58 PM, Darin Fisher da...@chromium.org wrote:
There are some caches in webkit (the resource cache in particular, but
there are others) that would be nice to share between processes.
If you look into this, note that there are major tricky issues here around
Peter,
I am aware there will be synchronization issues. I am a grad student who has
been studying concurrent and lock-free data structures for a while now. I'm
actually hoping to apply some of my research in Chromium as a proof of
concept.
I'm also interested in looking into state that is
On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote:
I'm also interested in looking into state that is already shared but makes
excessive use of locking and may be hindering performance.
I'm not aware of anything that really falls into this category. We share
the visited
On Mon, Jan 4, 2010 at 5:17 PM, Fady Samuel fadysam...@gmail.com wrote:
I am aware there will be synchronization issues. I am a grad student who has
been studying concurrent and lock-free data structures for a while now. I'm
actually hoping to apply some of my research in Chromium as a proof of
Automatically closing tree for check deps on Chromium XP
http://build.chromium.org/buildbot/waterfall/builders/Chromium%20XP/builds/9486
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Chromium%20XP
--= Automatically closing tree for check deps on Chromium XP =--
Revision:
On Mon, Jan 4, 2010 at 5:48 PM, Fady Samuel fadysam...@gmail.com wrote:
So as Peter said a lot of this cache state will not be used in multiple
tabs because many of these tabs will be different webpages. That's not to
say that one doesn't open multiple pages from a single site however, in
Thanks Adam,
So as Peter said a lot of this cache state will not be used in multiple tabs
because many of these tabs will be different webpages. That's not to say
that one doesn't open multiple pages from a single site however, in which
case the image cache might have a lot replication overhead.
Sorry, one last thing I would be interested in looking into: fault Tolerance
of shared state.
In particular, can a crashing process currently break shared data structures
thus breaking the whole browser (e.g. leaving shared data structures in an
inconsistent state)?
Thanks,
Fady
On Mon, Jan 4,
(re-adding chromium-dev)
On Mon, Jan 4, 2010 at 5:58 PM, Fady Samuel fadysam...@gmail.com wrote:
Was this done to reduce memory overhead?
No, it was done because the newly opened pages and the original pages can
script each other. From what I understand, making sites in different
processes
On Mon, Jan 4, 2010 at 6:32 PM, Fady Samuel fadysam...@gmail.com wrote:
I know I'm asking you a lot of questions here.
And you keep removing chromium-dev. Why? I'm not the knowledgeable person
about much of this stuff, I'm just trying to be helpful.
Alex mentioned the Webkit DOM tree,
On Mon, Jan 4, 2010 at 6:55 PM, Fady Samuel fadysam...@gmail.com 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
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
If you don't build on linux, you can stop reading now.
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
I'm not disagreeing with you. Yes, the script needs to see a coherent state
as it executes BUT the renderer only needs a logically consistent snapshot,
correct? So the script can work on the most current version of the DOM,
while the renderer does its thing to produce a bitmap from the snapshot?
Charles, this is awesome! Thanks!
Fady
On Mon, Jan 4, 2010 at 10:17 PM, Charles Reis cr...@chromium.org 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
34 matches
Mail list logo
