diff options
| author | darin@google.com <darin@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-08-29 19:27:49 +0000 |
|---|---|---|
| committer | darin@google.com <darin@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-08-29 19:27:49 +0000 |
| commit | 83aad14e14607a1bf1bea7c94d2cf71324b8a2d0 (patch) | |
| tree | 473ba21deb70bd5a6ea5ee9bf53755e750930bce /chrome/browser | |
| parent | f937fdab0eb469bc99ba79db3e66e30ba5d02fa5 (diff) | |
| download | chromium_src-83aad14e14607a1bf1bea7c94d2cf71324b8a2d0.zip chromium_src-83aad14e14607a1bf1bea7c94d2cf71324b8a2d0.tar.gz chromium_src-83aad14e14607a1bf1bea7c94d2cf71324b8a2d0.tar.bz2 | |
Fix net_unittests hang observed on Vista. It turns out that a subpump was
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
Diffstat (limited to 'chrome/browser')
0 files changed, 0 insertions, 0 deletions