This is a just minor concern regarding NamedPipe destruction waits for around 8(or the timeout seconds given to launchWorkerProcess()) seconds unneccesarily on macOS based apps that use IPC like plugin scanner, etc.
To demonstrate: Run juce’s AudioPluginHost out-of-process scanner and notice while at the end the scanner waits for around 8 seconds with no operation getting performed before getting finished.
The reason: When worker process gets destructed and InterProcessConnection::disconnect() gets called from the main thread, NamedPipe::close() waits to writelock the lock which has got readlocked already by NamedPipe::Pimpl::read() from JUCE IPC thread. While no data is coming in through, NamedPipe::Pimpl::read() waits for the timeout seconds(by default 8) and then exits.
The supposed fix: While no data is coming in, NamedPipe::Pimpl::read() checks the atomic bool Pimpl::stopReadOperation periodically if it should exit. But it is never set to true by NamedPipe::close() because it waits for the lock before setting it.
Fix: If Pimpl::stopReadOperation is set to true in NamedPipe::close before trying to get the writelock, the issue gets solved.
