Re-enable DirectoryWatcherTest.SubDir on Vista

Re-enable DirectoryWatcherTest.SubDir on Vista

BUG=5072

[Paweł Hajdan Jr., 2009-01-02 16:54:00]

I managed to reproduce the failure on Vista, and tested this fix on XP and
Vista. Should be ok now.

[M-A Ruel, 2009-01-02 20:47:21]

That looks great, thanks for looking into it. LGTM, no need to snapshot again.

http://codereview.chromium.org/17046/diff/1/3
File base/directory_watcher_unittest.cc (right):

http://codereview.chromium.org/17046/diff/1/3#newcode138
Line 138: #if defined(OS_WIN)
If the flush was done in WriteTestDirFile(), you could reduce kWaitForEventTime
to ~50ms and significantly speedup this test. What do you think?

[Paweł Hajdan Jr., 2009-01-03 10:48:34]

On 2009/01/02 20:47:21, M-A wrote:
> That looks great, thanks for looking into it. LGTM, no need to snapshot again.

I don't understand it. On my XP machine SubDir test passes. On buildbot it fails
(1 notification instead of expected 0). Do you have some idea?

> http://codereview.chromium.org/17046/diff/1/3#newcode138
> Line 138: #if defined(OS_WIN)
> If the flush was done in WriteTestDirFile(), you could reduce
kWaitForEventTime
> to ~50ms and significantly speedup this test. What do you think?

I'm a bit afraid it could make the test flaky. In theory the flush should result
in an "almost instant" notification. In reality, it doesn't have to be the case.
If the underlying code is ok, we won't notice the difference. But if it's wrong,
we might get false-negatives.

[M-A Ruel, 2009-01-03 13:57:52]

On 2009/01/03 10:48:34, Paweł Hajdan Jr. wrote:
> I don't understand it. On my XP machine SubDir test passes. On buildbot it
fails
> (1 notification instead of expected 0). Do you have some idea?

No, I'll take a look next week.

> > http://codereview.chromium.org/17046/diff/1/3#newcode138
> > Line 138: #if defined(OS_WIN)
> > If the flush was done in WriteTestDirFile(), you could reduce
> kWaitForEventTime
> > to ~50ms and significantly speedup this test. What do you think?
> 
> I'm a bit afraid it could make the test flaky. In theory the flush should
result
> in an "almost instant" notification. In reality, it doesn't have to be the
case.
> If the underlying code is ok, we won't notice the difference. But if it's
wrong,
> we might get false-negatives.

If the underlying system is a VM, thread scheduling can be very flaky. Since the
"almost instant" notification is probably generated from another system thread,
we can expect significant delays. (Some other tests need to sustain having
random threads hung for > 1 second due to VM thread scheduling issues)