mirror of
https://github.com/facebook/sapling.git
synced 2024-10-09 08:18:15 +03:00
6cc56a6f81
Summary: The FuseChannel unit tests would sometimes hang because a worker thread would still be stuck in a blocking read() call. The issue appears to be that the kernel would often automatically restart the interrupted read(), so the worker would never wake up. This switches the code from using SIGPIPE to wake up, and instead uses SIGUSR2, and installs a handler for SIGUSR2 with the SA_RESTART flag unset. It's possible that this was an issue only for the unit tests, where the FUSE device is a socket. I'm not sure if the kernel would automatically restart read operations on a real FUSE device. There are still theoretically some race conditions here, since `requestSessionExit()` could be called right after a worker thread checks `(runState_` and before it enters the blocking `read()` call. Fixing that would likely require switching to something like `folly::EventBase` or manually using epoll. Fortunately I haven't seen that be an issue in practice so far. Reviewed By: chadaustin, wez Differential Revision: D7282002 fbshipit-source-id: 99d29de13a7858dd25f258fdc94d8f8c71ee84d9 |
||
|---|---|---|
| .. | ||
| config | ||
| fuse | ||
| inodes | ||
| journal | ||
| model | ||
| rocksdb | ||
| service | ||
| sqlite | ||
| store | ||
| takeover | ||
| testharness | ||
| utils | ||