The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fa906c38bf1f7a693702ea2d72c74f7ed16afc4a

commit fa906c38bf1f7a693702ea2d72c74f7ed16afc4a
Author: Robert Liao <robliao@chromium.org>
Date: Wed Feb 14 05:19:38 2018

Convert the Linux Inotify File Path Watcher to use PlatformThread

The previous implementation created a regular MessageLoop based thread
and posted a single perpetually running task to it, effectively
blocking this MessageLoop.

With MessageLoop redirection to the Task Scheduler, a flush would
result in a hang as this task would never return.

This change moves that single task into its own ThreadMain and changes
the use of Thread to a non-joinable PlatformThread.

BUG= 810804 

Change-Id: I364acee59f9dd5d80a9c57ebc9d8158ee5faa9c4
Reviewed-on: https://chromium-review.googlesource.com/911902
Commit-Queue: Robert Liao <robliao@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536652}
[modify] https://crrev.com/fa906c38bf1f7a693702ea2d72c74f7ed16afc4a/base/files/file_path_watcher_linux.cc

As noted in the CL, I don't think that there is actually any need for the InotifyReader to sit blocked in select() in a single task; can we update the implementation to just use FileDescriptorWatcher like everything else?

Replaying response from https://chromium-review.googlesource.com/911902

It's an interesting idea. The goal of this change was to unblock redirection of the MessageLoop to the task scheduler and simply migrating the loop was a low-risk no-op way to do it. I have no objects to changing the implementation after that.