| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Inititialize().
BUG=7467
Review URL: http://codereview.chromium.org/24006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9354 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=6661
Review URL: http://codereview.chromium.org/18775
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8872 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
R=wtc
Review URL: http://codereview.chromium.org/4253
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2557 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flaky DNS queries from the unit tests.
Note: some unit tests still connect to www.google.com. My plan
is to resolve those in a subsequent CL.
R=wtc
BUG=2635
Review URL: http://codereview.chromium.org/4022
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2545 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being run within shell32, which was causing our kHaveWorkMsg to get dispatched.
However, because that was occuring outside the context of a MessagePump::Run
call, the handler for kHaveWorkMsg was returning early. Unfortunately, this
means that it was failing to reset the have_work_ sentinel to 0. Because of
that future calls to ScheduleWork would always be a no-op (as they return early
when have_work_ is already set to 1). The proper fix is to just re-order the
calls so that ProcessPumpReplacementMessage always runs in response to
kHaveWorkMsg, but we still suppress calling DoWork until we are inside
MessagePump::Run.
TBR=rvargas,jar
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1544 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
TBR=rvargas
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1540 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
Since only one test needed a MessageLoop, I decided to only give that single test a MessageLoop. I used a MessageLoopForIO (subclass of MessageLoop) for future use when the disk cache leverages MessageLoopForIO for asynchronous IO.
TBR=rvargas
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1428 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
|