InterprocessConnection

#1

Hello,
So I’m trying to setup a pipe for a little IPC between a Juce app and a non-Juce app. In my Juce app I’m subclassing InterprocessConnection and creating an instance and calling InterprocessConnection::createPipe(“myPipeName”);

In my non-Juce app, I’m doing regular win32 with CreateFile to connect to the same named pipe.

Two problems:
The Juce app, in InterprocessConnection::readNextMessageInt() only waits a max of 5 seconds before giving up on the pipe. Question there is, uh, why? And how to make my Juce app wait for messages via the pipe forever?

Second problem is that, even if I can get my other app to send something within the allotted 5 seconds, I do not get a messageReceived() in my Juce app (yes, the client pipe did ‘openexisting’ successfully). So, the question here would be, have pipes been thoroughly tested?

Thanks,
Paul

#2

I guess the timeout is 5 seconds because nobody’s ever asked for it to be changed! And if you’re sending a blob of data between processes on the same machine, 5 seconds is a very long time, isn’t it? You could pass gigabytes across in 5 seconds… I will add a method to change the timeout though.

And pipes have been fairly well tested, but only in a juce-to-juce way. Does juce demo IPC page work ok?

#3

I’d venture a guess an say the pipe timeout was some cut-n-paste logic from the socket IPC handling. With sockets, you can create a InterprocessConnectionServer to create InterprocessConnections when needed to handle the incoming request, and in that case 5 seconds is plenty of time. But for pipes, there is no server implementation, so the InterprocessConnection class needs to wait indefinitely for connections.

If my guess above is correct, then a timeout setting is not what’s needed. Just changing the timeout from the default 5000ms to 0 in InterprocessConnection::readNextMessageInt() for pipes is all that is needed.

I did try a remote Juce process to connect to the pipe and had the same non-success in triggering a messageRecevied event.

#4

Yes, you’re right - that timeout should be -1 by default.

When you say “remote”, you don’t mean on a different machine, do you? Pipes will only work between processes, not over a network. I just tried two juce demos, and it works fine with a pipe for me.

#5

Thanks. I’ll update that in my source in the meantime.
For remote, I did mean on the same machine. Bad choice of word.

#6