| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
When a test doesn't hang or crash, it can run on the bots
and on developers' machines.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/269104
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29279 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
Not filing a bug because timer test are difficult to make
not-flaky on the buildbots. However, added comments to the code
so that people who touch this area remember to run all tests.
Review URL: http://codereview.chromium.org/40312
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11276 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
const per style compliance).
Preliminary work to enforce new PRESUBMIT.py rules:
- <=80 cols
- no trailing whitespaces
- svn:eol-style=LF
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10791 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
made once the DelayTimer has been destroyed.
Review URL: http://codereview.chromium.org/27234
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10520 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
When working on the comments for r10071 I typoed and changed a
50 to 1.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10072 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch reworks bitmap transport on all platforms. Linux and Mac
are switched from serialising bitmaps over the IPC channel to using
shared memory. All platforms gain a shared memory mapping cache on the
host side.
The concept of a TransportDIB (device independent bitmap) is added to
encapsulate most of the platform specifics.
On Linux, we use SysV shared memory. This is because X shared pixmaps,
which predate POSIX SHM, can only use SysV. By using SysV between
renderer and browser, we open up the possibility to map the shared
memory directly from the renderer to the X server.
On Mac, we use POSIX shared memory. However, since this needs
filesystem access and the Mac renderer is sandboxed from the
filesystem, we add two new messages from renderer -> browser:
The first, AllocTransportDIB, synchronously creates a transport DIB in
the browser and passes a handle back to the renderer. The second,
FreeTransportDIB, asynchronously, notifies the browser that it may
close its handle to the shared memory region.
On Mac, the shared memory regions are identified by their inode
numbers on the wire. This means that the browser must keep handles
open to all the allocated shared memory regions (since an inode number
is insufficient to map the region). The alternative design is that the
renderer passes the file descriptor with each paint operation. Since
passing file descriptors is special case in the code, I felt that it
would be best to minimise their use. Creating and freeing transport
DIBs are relatively rare operations relative to paints and scrolls.
On Windows, most of the code remains the same, except that Windows now
uses the mapping cache added in this patch. This allows the browser to
maintain a shared memory mapping for a transport DIB over several
paints. Previously it mapped and unmapped for every operation, causing
lots of TLB and VM churn.
Review URL: http://codereview.chromium.org/21485
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10071 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
original timer in the receiver method. This happens
in the events of following sequence:
- A TimerTask is created on message loop
- When TimerTask::Run is called, it nullifies
timer_->delayed_task.
- The receiver method is dispatched, and inside
the method, the timer_ is deleted. Since
timer_->delayed_task being null, the timer_
destructor will not orphan the task.
- After the method is returned, message loop
deletes the task which will deref the
dangling pointer to timer_.
I also tried to add a unit test to this. The best
I can come up with is making the test process
crash/fail in full page heap or purify environment.
BUG=1570948
Review URL: http://codereview.chromium.org/20111
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9368 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Post Mortem on why yesterday's fix was bogus:
The motivation for this change was because a separate CL had a OneShotTimer<> as
part of a Singleton class. The Singleton is cleaned up in the AtExit manager,
which currently runs after the MessageLoop is destroyed. The following
sequence left a dangling pointer:
1) Start a OneShotTimer
- Creates a task and registers on the MessageLoop
2) Destroy MessageLoop (this deletes all Pending Tasks)
3) Destroy your OneShotTimer
- Tries to reference a dangling pointer for the already-deleted task.
The fix was to modify the Task such that at destruction it would zero-out the
wrapper's pointer to the Task. Now step 3 would not reference a bogus pointer.
Unfortunately, the fix is broken. The timers work by having a wrapper Timer
class (BaseTimer_Helper) and a Task. The Task has a pointer back to its wrapper
and the wrapper has a pointer to the task. For the case where a timer is
re-started from within its Run() loop, things fail:
1) Start a RepeatingTimer
2) Timer fires via the MessageLoop
MessageLoop calls Run()
3) Run() restarts the timer, which creates a new Task but reuses the
same BaseTimer_Helper.
BaseTimer_Helper's timer pointer now points to the NEW timer
4) The MessageLoop destroys the Task
The new code zeroes out the task pointer in the
BaseTimer_Helper, breaking the newly restarted timer.
This fix is the same as yesterday's fix, except:
1) More comments
2) Added extra check at line 169. Don't reset the Task pointer when
destroying the Task if the Timer does not point to the Task being
destroyed.
I'm confident, but not 100% positive that this fixes the problem. I did
reproduce *something* using PageHeap which now seems to be gone, but I
can't quite confirm.
Review URL: http://codereview.chromium.org/13067
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6251 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
it on a clean and clobbered tree, it caused all the
failures
Review URL: http://codereview.chromium.org/12870
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6220 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
it's still breaking the tests
Review URL: http://codereview.chromium.org/12868
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6218 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
on the distributed tests.
TBR
Review URL: http://codereview.chromium.org/13042
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6205 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you have a OneShotTimer pending, and you destroy your
message loop, the cleanup of the timer will use memory
which was already freed by the MessageLoop. When the
MessageLoop shuts down, it deletes pending tasks.
BaseTimer did not provide a virtual destructor to cleanup
its "base". Thus, when the actual OneShotTimer cleaned
up, it would use deleted memory.
This manifested for me when I had accidentally had cleanup
of a oneshottimer occurring through the Singleton, which
occurs AtExit, after the messageloop is already gone.
Created a unit test for this, which does trip the assert due
to heap corruption.
Review URL: http://codereview.chromium.org/13023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6190 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/7995
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4022 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
This CL also eliminates TaskBase by creating a simple PendingTask struct that is allocated inline within a std::queue used to implement the queues in the MessageLoop class.
R=jar
Review URL: http://codereview.chromium.org/483
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1825 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
escaped my working copy.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1712 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
variables into the Task subclass.
Also included in this change: deprecate MessageLoop::timer_manager(), and change consumers over to use OneShotTimer or RepeatingTimer.
R=beng
BUG=1346553
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1684 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1648 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Major changes:
OneShotTimer and RepeatingTimer become template classes that no longer require
a Task or a Timer object. They just use PostDelayedTask. Under the hood that
still uses a Timer object.
The API is much simpler for consumers as they now no longer need to worry about
allocating a Task or managing the lifetime of the object pointer held by the
Task.
I added some new unit tests to timer_unittest.cc to cover the API.
I preserved the old TimerManager / Timer API for now, but I plan to soon kill
it.
R=brettw
BUG=1346553
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1502 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
static variable
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1369 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL introduces a Type enum to MessageLoop, and I also created subclasses of MessageLoop corresponding to the non-default types: MessageLoopForIO and MessageLoopForUI.
I moved all of the platform-specific MessageLoop APIs onto either MessageLoopForIO or MessageLoopForUI. MessageLoopForIO gets the Watcher API, and MessageLoopForUI gets the Observer and Dispatcher APIs. Under the hood, both are implemented in terms of MessagePumpWin, but that will change in a future CL.
The Thread class is changed to allow the consumer to specify the Type of MessageLoop they want to have setup on the created thread.
I re-organized message_loop_unittest.cc and timer_unittest.cc so that I could exercise all (or most) of the tests against each type of MessageLoop.
Note: I know that "explicit MessageLoop(Type type = TYPE_DEFAULT);" is in violation to the style-guide's restriction against default arguments. I'm working on finding a decent solution to that problem. Please ignore this issue for now.
The corresponding chrome/ changes are coming in a separate CL due to Reitveld data size limitations.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1362 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Note that the targets for libskia and libicuuc still exclude themselves from -Werror.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1205 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
No code change.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@865 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Please note that the goal of this CL is merely to move the Windowisms out of timer.cc and into message_loop.cc. Next up will be to refactor message_loop.cc so that the Windowisms are further isolated.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@734 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
|