I finally found the problem and will share my solution here in case somebody else has a similar problem:
Initial situation:
I have several applications based on Juce. One of it is a little logging window that all my other applications are using. For this purpose I'm using Juce's InterprocessCommunication class for creating several NamedPipes, where other processes can connect and write to.
My problem was that each process is trying to connect via the InterprocessConnection::connectToPipe( ) method to the first pipe in the list and if the attemp fails it takes the next one and so on until it finds a free pipe. In Juce 1.53 this worked perfectly because the InterprocessConnection::connectToPipe( ) returned false in case another process is using the same pipe already. In the new Juce version, this function returned true although another process was already using the same pipe.
I traced the problem down to the NamedPipe::openInternal( ) method, which is always returning true in case the createPipe parameter is specified as false (which is the case for my client applications) without actually trying to connect to the pipe.
bool NamedPipe::openInternal (const String& pipeName, const bool createPipe)
{
pimpl = new Pimpl (pipeName, createPipe);
if (createPipe && pimpl->pipeH == INVALID_HANDLE_VALUE)
{
pimpl = nullptr;
return false;
}
return true;
}
After changing this method to the following everything worked out fine:
bool NamedPipe::openInternal (const String& pipeName, const bool createPipe)
{
pimpl = new Pimpl (pipeName, createPipe);
if (createPipe)
{
if(pimpl->pipeH == INVALID_HANDLE_VALUE)
{
pimpl = nullptr;
return false;
}
return true;
}
return pimpl->connect(100);
}
@Jules: is this a bug in the current Juce version or am I just using the NamedPipe class in a way I'm not supposed to? Is there a better way to implement my use case?