| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/351029
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36378 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/495002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35321 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
BUG=26749
Review URL: http://codereview.chromium.org/360042
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31136 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
to be processed when returning to an outer loop.
BUG=11470 13442 13468
TEST=base_unittests, test cases in bugs
Review URL: http://codereview.chromium.org/146006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19272 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
Also, there's no point in using scoped_ptr for event_ anymore,
so removed that.
Should fix http://crbug.com/10503 "Crash in network layer"
Review URL: http://codereview.chromium.org/87045
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14233 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleanup the separation between MessagePumpForUI and
MessagePumpForIO, and convert the latter to use Completion
Ports instead of MsgWaitForMultipleobjects to sleep
when idle.
Remove all traces of Windows messages from MessagePumpForIO,
remove the transitional API of completion port notifications
and remove WatchObject API.
Modify all callers of RegisterIOHandler so that they are no
longer using RegisterIOContext, and also handle properly
the new semantics of completion ports (notifications even when
the IO completes immediately).
Add a new interface to allow proper cleanup of disk cache (to
replace code that was waiting for pending APCs from the destructor).
Add a way for the message pump to perform cleanup of abandoned IO.
BUG=B/1344358, 3497, 3630
TESt=unit tests
R=darin
Review URL: http://codereview.chromium.org/8156
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5021 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
|
|
|
|
|
|
|
|
|
|
|
| |
through the windows version of the message pump.
As a first step, actual IO processing is still performed using WatchObject instead of
using completion ports.
Review URL: http://codereview.chromium.org/1950
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3157 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2510 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
R=jar
BUG=2559
Review URL: http://codereview.chromium.org/4041
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2509 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1961 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
and thereby avoid unexpected crashes.
r=jar
Review URL: http://codereview.chromium.org/1664
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1959 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1892 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
cannot clear MessageLoop::current() until all of the tasks have been deleted.
I wrote a loop to make sure that the queues are all empty. This could be abused, obviously. Another approach would be to CHECK that the second loop doesn't do anything. Thoughts?
R=jar
Review URL: http://codereview.chromium.org/1829
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1891 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
platforms. This is actually just a first-step toward the real fix which is to
use MessagePumpDefault on all platforms on non-UI and non-IO threads.
This CL also fixes some GCC compilation errors. I renamed MessageLoopOwnable
to TaskBase, which seems more appropriate since a MessageLoopOwnable has a
next Task pointer and clearly is only meaningful in the context of Task. (I
wonder why it is even a separate class, but that is another issue.) I had to
make the next_task / set_next_task methods public since they are used by an
inner class of MessageLoop. Perhaps those inner classes should be made into
top-level classes, but that seemed like too much to change at this time.
R=jar,mmentovai
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1045 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MessageLoop. A MessageLoop now has a MessagePump.
This will make it possible to port the MessagePump interface to other platforms
as well as to use an IO completion port for our worker threads on Windows.
Currently, there is only MessagePumpWin, which attempts to preserve the
pre-existing behavior of the MessageLoop.
API changes to MessageLoop:
1. MessageLoop::Quit means return from Run when the MessageLoop would
otherwise wait for more work.
2. MessageLoop::Quit can no longer be called outside the context of an active Run
call. So, things like this:
MessageLoop::current()->Quit();
MessageLoop::current()->Run();
are now:
MessageLoop::current()->RunAllPending();
3. MessageLoop::Quit can no longer be called from other threads. This means that
PostTask(..., new MessageLoop::QuitTask()) must be used explicitly to Quit across
thread boundaries.
4. No protection is made to deal with nested MessageLoops involving watched
objects or APCs. In fact, an assertion is added to flag such cases. This is a
temporary measure until object watching and APC facilities are removed in favor
of a MessagePump designed around an IO completion port.
As part of this CL, I also changed the automation system to use an
IPC::ChannelProxy instead of an IPC::Channel. This moves the automation IPC
onto Chrome's IO thread where it belongs. I also fixed some abuses of
RefCounted in the AutomationProvider class. It was deleting itself in some
cases! This led to having to fix the ownership model for AutomationProvider,
which explains the changes to AutomationProviderList and so on.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@928 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
in test (it was a redundant use of quit which was caught
when I wrote code to detect this construct, which caused
hangs in some race scenarios).
r=darin
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@848 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
TBR
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@299 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
I use a counter of MessageLoop::Quit() calls so that I can re-post "extra" calls when MessageLoop::Run() terminates. This assures that no quits are lost... but I'm not sure if some code abused the Quit() calls, and already posts many-too-many quits :-/. I want to see if the tree tests go red, and how the distributed reliability test responds.
The test should already pass the basic unit_test and base_unittest, but I'm not sure what the rest of the UI tests etc will do. If I'm lucky, they'll be "less" flakey. ...but they may just go red all over :-(
TBR
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@298 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
BUG=1282556
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@112 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
|