2nd try: FileAPI: Split recursive remove into multiple tasks.

2nd try: FileAPI: Split recursive remove into multiple tasks.

Original review page: https://codereview.chromium.org/12018017/

While this change makes each recursive delete run slower, concurrent jobs can run without waiting for the entire recursive job to finish.

Recursive remove end-to-end (200 files, 120 dirs, 4-level tree, total 100MB):
Before this change: Ave: 72.94 msec, Stddev: 3.571 msec
After this change: Ave:129.54 msec, Stddev: 25.368 msec

It takes 1.76 times slower than before by average (we can probably do more optimization as this implementation doesn't care much about it), while another concurrent file task called immediately after the delete could finish in 1-5 msec (while back then it needed to wait for 70-80 msec).

BUG=146215
TEST=content_unittests:.*File.*,content_browsertests:FileSystemLayoutTests.OpRemove


Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=179102

[kinuko, 2013-01-24 10:39:07]

Sorry, can you take another look.. Diff between patch set 1 and 2 is the diff
from original review.

[tzik, 2013-01-24 10:41:16]

lgtm

[kinuko, 2013-01-25 03:32:20]

Fixed more leaks and bots look ok now (valgrind errors look irrelevant). 
Operation memory management in Syncable case is a bit messy, I'd like to try
cleaning up the FSO lifetime issue in follow-up patches... can you take one more
look?  Thanks!

[kinuko, 2013-01-28 01:50:22]

Friendly ping.

[tzik, 2013-01-28 02:38:10]

lgtm

[kinuko, 2013-01-28 02:44:21]

Thanks!


On Mon, Jan 28, 2013 at 11:38 AM, <tzik@chromium.org> wrote:

> lgtm
>
>
>
>
https://codereview.chromium.**org/12051055/<https://codereview.chromium.org/1...
>

[commit-bot: I haz the power, 2013-01-28 03:29:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/kinuko@chromium.org/12051055/18002

[commit-bot: I haz the power, 2013-01-28 05:10:52]

Change committed as 179102