ImportantFileWriter: check return value of PostTask...

ImportantFileWriter: check return value of PostTask
when writing to the disk, so we can be sure it doesn't lose data.

Also fix tests that misused things.

TEST=none
BUG=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=77695

[Paweł Hajdan Jr., 2011-03-07 21:09:20]

What do you think? My plan is to switch to a Windows checkout and fixing the
remaining test failures later. It's very slow if I do it through a trybot
because of the crashes (can only fix tests one at a time).

[sanjeevr, 2011-03-07 23:26:25]

http://codereview.chromium.org/6627060/diff/1/chrome/common/important_file_wr...
File chrome/common/important_file_writer.cc (right):

http://codereview.chromium.org/6627060/diff/1/chrome/common/important_file_wr...
chrome/common/important_file_writer.cc:119: write_task->Run();
This will not work because PostTask will delete the task if it fails.

[Paweł Hajdan Jr., 2011-03-08 09:11:28]

PTAL

http://codereview.chromium.org/6627060/diff/1/chrome/common/important_file_wr...
File chrome/common/important_file_writer.cc (right):

http://codereview.chromium.org/6627060/diff/1/chrome/common/important_file_wr...
chrome/common/important_file_writer.cc:119: write_task->Run();
On 2011/03/07 23:26:25, sanjeevr wrote:
> This will not work because PostTask will delete the task if it fails.

Done.

[sanjeevr, 2011-03-08 19:42:05]

LGTM with a spelling nit.

http://codereview.chromium.org/6627060/diff/7001/chrome/common/important_file...
File chrome/common/important_file_writer.cc (right):

http://codereview.chromium.org/6627060/diff/7001/chrome/common/important_file...
chrome/common/important_file_writer.cc:112: // to fail, but if it does, avoid
loosing data and just hit the disk
Spelling Nit: loosing => losing

[Paweł Hajdan Jr., 2011-03-09 09:09:21]

Brett/Antony: could you take a look?

http://codereview.chromium.org/6627060/diff/7001/chrome/common/important_file...
File chrome/common/important_file_writer.cc (right):

http://codereview.chromium.org/6627060/diff/7001/chrome/common/important_file...
chrome/common/important_file_writer.cc:112: // to fail, but if it does, avoid
loosing data and just hit the disk
On 2011/03/08 19:42:05, sanjeevr wrote:
> Spelling Nit: loosing => losing

Done.

[brettw, 2011-03-09 18:06:28]

LGTM

[asargent_no_longer_on_chrome, 2011-03-09 18:13:01]

http://codereview.chromium.org/6627060/diff/15001/chrome/browser/extensions/t...
File chrome/browser/extensions/test_extension_prefs.cc (right):

http://codereview.chromium.org/6627060/diff/15001/chrome/browser/extensions/t...
chrome/browser/extensions/test_extension_prefs.cc:69:
MessageLoop::current()->RunAllPending();
The code before was waiting for the file loop to run all pending tasks, but
you've changed it to MessageLoop::current(), which I think will return the UI
thread's MessageLoop. Doesn't this create a race condition such that where we
recreate the pref service below this block, the I/O on the file thread might not
be finished in time?

[Paweł Hajdan Jr., 2011-03-09 18:22:14]

http://codereview.chromium.org/6627060/diff/15001/chrome/browser/extensions/t...
File chrome/browser/extensions/test_extension_prefs.cc (right):

http://codereview.chromium.org/6627060/diff/15001/chrome/browser/extensions/t...
chrome/browser/extensions/test_extension_prefs.cc:69:
MessageLoop::current()->RunAllPending();
On 2011/03/09 18:13:01, Antony Sargent wrote:
> The code before was waiting for the file loop to run all pending tasks, but
> you've changed it to MessageLoop::current(), which I think will return the UI
> thread's MessageLoop. Doesn't this create a race condition such that where we
> recreate the pref service below this block, the I/O on the file thread might
not
> be finished in time?

There can be only one MessageLoop per thread. My interpretation of the previous
code is that file_loop was totally equivalent to MessageLoop::current() after
the declaration MessageLoop file_loop.

[asargent_no_longer_on_chrome, 2011-03-09 18:33:25]

http://codereview.chromium.org/6627060/diff/15001/chrome/browser/extensions/t...
File chrome/browser/extensions/test_extension_prefs.cc (right):

http://codereview.chromium.org/6627060/diff/15001/chrome/browser/extensions/t...
chrome/browser/extensions/test_extension_prefs.cc:69:
MessageLoop::current()->RunAllPending();
On 2011/03/09 18:22:14, Paweł Hajdan Jr. wrote:
> On 2011/03/09 18:13:01, Antony Sargent wrote:
> > The code before was waiting for the file loop to run all pending tasks, but
> > you've changed it to MessageLoop::current(), which I think will return the
UI
> > thread's MessageLoop. Doesn't this create a race condition such that where
we
> > recreate the pref service below this block, the I/O on the file thread might
> not
> > be finished in time?
> 
> There can be only one MessageLoop per thread. My interpretation of the
previous
> code is that file_loop was totally equivalent to MessageLoop::current() after
> the declaration MessageLoop file_loop.
But it was registering file_loop as the message loop for the file thread just
after creating it. Are you saying that doesn't work?

[Paweł Hajdan Jr., 2011-03-09 20:40:03]

Please take another look.

If it looks good, could you please add it to the commit queue (the little
"commit" checkbox)? That'd save me some time when working on part #2 of this
change (enabling the DCHECK also on Windows).

http://codereview.chromium.org/6627060/diff/15001/chrome/browser/extensions/t...
File chrome/browser/extensions/test_extension_prefs.cc (right):

http://codereview.chromium.org/6627060/diff/15001/chrome/browser/extensions/t...
chrome/browser/extensions/test_extension_prefs.cc:69:
MessageLoop::current()->RunAllPending();
On 2011/03/09 18:33:25, Antony Sargent wrote:
> But it was registering file_loop as the message loop for the file thread just
> after creating it. Are you saying that doesn't work?

After a more detailed look I think MessageLoop::current() was _correct_ but
potentially fragile. I've switched to waiting for an event signaled on FILE
thread. This will work both in case FILE thread is a "mock" thread running on
the same message loop, or a "real" thread with its own message loop.

Thank you for catching this, I think it is an important issue.

[asargent_no_longer_on_chrome, 2011-03-09 20:53:17]

Ok, I think the change in test_extension_prefs.cc looks good now. However in
looking things over again I noticed in a few of the extension test files you're
passing the same message loop to two different threads - isn't that invalid?

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/e...
File chrome/browser/extensions/extension_menu_manager_unittest.cc (right):

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/e...
chrome/browser/extensions/extension_menu_manager_unittest.cc:36:
file_thread_(BrowserThread::FILE, &message_loop_),
same message loop to 2 threads?

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/e...
File chrome/browser/extensions/extension_prefs_unittest.cc (right):

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/e...
chrome/browser/extensions/extension_prefs_unittest.cc:67:
file_thread_(BrowserThread::FILE, &message_loop_) {
same message loop to 2 threads?

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/e...
File chrome/browser/extensions/extension_updater_unittest.cc (right):

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/e...
chrome/browser/extensions/extension_updater_unittest.cc:714: BrowserThread
file_thread(BrowserThread::FILE, &message_loop);
same message loop to 2 threads?

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/t...
File chrome/browser/extensions/test_extension_prefs.cc (right):

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/t...
chrome/browser/extensions/test_extension_prefs.cc:74:
EXPECT_TRUE(io_finished.Wait());
Nice, this looks much better.

[commit-bot: I haz the power, 2011-03-09 21:24:53]

Try job failure for 6627060-21003 on linux:
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=linux&numb...

[Paweł Hajdan Jr., 2011-03-10 07:30:35]

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/e...
File chrome/browser/extensions/extension_menu_manager_unittest.cc (right):

http://codereview.chromium.org/6627060/diff/21003/chrome/browser/extensions/e...
chrome/browser/extensions/extension_menu_manager_unittest.cc:36:
file_thread_(BrowserThread::FILE, &message_loop_),
On 2011/03/09 20:53:17, Antony Sargent wrote:
> same message loop to 2 threads?

In this case I'm absolutely sure this is valid. Here's how it works:

There are no two threads here, only one. There are two "labels" though, UI and
FILE. In the browser those are all real threads of course, each with its own
message loop. For tests however, it is often simpler to have just one message
loop (it also makes the test more deterministic).

BrowserThread maps thread labels (UI, FILE, IO and so on) to MessageLoops. It
can be seen as sort of a switchboard. Now when I'm using same message loop for 2
thread labels I'm saying I just don't want to create more threads, and I want
everything to run on the same thread.

Short story: it would be incorrect in the browser code, but in test code it is
perfectly fine, and makes things simpler. There are many other existing tests
doing so already.

[Paweł Hajdan Jr., 2011-03-10 09:18:19]

I just realized we still need to call RunAllPending to avoid hangs, eh.

Could you take another look? Another possible solution is to RunAllPending only
when we detect that FILE thread is the current thread (it's possible). It's
slightly more complicated, so I'm submitting the simpler solution for now.

[asargent_no_longer_on_chrome, 2011-03-10 20:23:08]

lgtm

[commit-bot: I haz the power, 2011-03-10 21:22:00]

Change committed as 77695