As in object I have this problem with InterprocessConnection::connectToSocket
I developed my app on Mac and with this code all works without errors (I use InterprocessConnection because I want my instances of plug-in to connected to another app that if it’s loaded could manages some of their parameters):
InterprocessMixerConnector::InterprocessMixerConnector(NodeGraph_PluginAudioProcessor& processor) : pluginProcessor(processor)
{
//some code
startTimer(1000); //if I comment this all works (obviously my plugin instance will never be connected)
}
InterprocessMixerConnector::~InterprocessMixerConnector()
{
//some code
stopTimer();
disconnect();
}
void InterprocessMixerConnector::connectionMade()
{
stopTimer();
//some code
}
void InterprocessMixerConnector::connectionLost()
{
startTimer(1000);
}
void InterprocessMixerConnector::timerCallback()
{
if (!isConnected())
{
connectToSocket ("localhost",
AYRA_NODE_GRAPH_MIXER_PORT,
1000);// here maybe it's better 999?
}
}
How can I do and why on windows it does block the app while on Mac not??
After investigating, the difference seems to stem from the low-level select function, which is used to wait until the socket becomes writable (i.e. it connected successfully).
On macOS, if the server’s socket is unavailable, select returns immediately, and using getsockopt to check the socket’s error state on the client results in ECONNREFUSED.
On Windows, select seems to wait for the timeout duration before returning. If the server’s socket is not available, then getsockopt indicates the error code WSAECONNREFUSED, which seems to have the same semantics as the POSIX ECONNREFUSED. So, the main difference is that this call blocks on Windows but not on macOS.
In order to avoid blocking your UI, I’d recommend calling connect from a background thread, like you suggested. You could also consider communicating over pipes instead of sockets, as the connection behaviour seems more consistent across platforms. That said, connectToPipe can still take a long time to return, even when it doesn’t reach the timeout, so it still shouldn’t be called from the UI thread.
I need to investigate more to determine whether the behaviour of connectToSocket can/should be made consistent across platforms.
