Linux 上由 FileSystemWatcher 导致的启动速度问题

[AlanIWBFT]

老问题了（ #1121 ）。我这里有两个 UE5 的worktree，若串行冷启动每个需要5秒左右，加在一起10秒多才能弹出主界面：

[git Watcher] Initialized in 322 ms
[combined Watcher] Initialized in 616 ms
[combined Watcher] Initialized in 774 ms
[combined Watcher] Initialized in 4550 ms
[wc Watcher] Initialized in 4580 ms

在读了 https://github.com/dotnet/runtime/blob/main/src/libraries/System.IO.FileSystem.Watcher/src/System/IO/FileSystemWatcher.Linux.cs 的代码之后，我建议重新研究

Task.Run(() => { combined.EnableRaisingEvents = true; });

的可行性，因为从源码看来，无论你在哪个阶段调用 Dispose()，都能调到内部的 StopRaisingEvents() 从而令持有 inotify handle 的工作线程退出。注释也表明反复快速的 start/stop 应该是没问题的

// Start running.  All state associated with the watch operation is stored in a separate object; this is done
// to avoid race conditions that could result if the users quickly starts/stops/starts/stops/etc. causing multiple
// active operations to all be outstanding at the same time.

不过，有一种可能性是这个 EnableRaisingEvents 的 Task 本身还没有执行就要 Dispose，这个就需要处理了

[AlanIWBFT]

概念验证了一下，还行

_watcherInitializationTasks.Add(Task.Run(async () => { combined.EnableRaisingEvents = true; return combined; }));
// ...
foreach (var task in _watcherInitializationTasks)
{
    Task.Run(async () =>
    {
        var watcher = await task;
        watcher.EnableRaisingEvents = false;
        watcher.Dispose();
    });
}

_watcherInitializationTasks.Clear();

[love-linger]

我提交了一版修复。你能帮我测试一下吗？我已经在 macOS 和 Windows 上测试通过了。但我现在没有了 Linux 设备。

I've pushed a commit that tries to fix this issue. Could you please test it for me

[AlanIWBFT]

成功。我检查了 https://github.com/dotnet/runtime/blob/main/src/libraries/System.IO.FileSystem.Watcher/src/System/IO/FileSystemWatcher.cs 的源码，其中有 StartRaisingEventsIfNotDisposed()，因此即便上面我说的情况出现，也不会引发问题。