(Solved) NamedPipe desctruction can be a little faster on macOS

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.

Are you testing with JUCE’s develop branch? There was a fix for something similar quite recently:

1 Like

No, I was testing with JUCE’s main branch and did not check with this. The changes in that commit was exactly what I was suggesting. The issue is solved then :+1: