I’m trying to establish an IPC between two plugin types that share some common code for communications handling. The named pipe solution looks good, but there is something I don’t really understand:
Here’s my connection procedure:
In the communications manager constructor (which is bound to a plugin type and will be created when the first instance of a plugin type is created), the name of the pipe to connect to the other type is created so that it is reversible (ie: the same name on both sides).
Plugin A (first to be instanciated) tries to connect to an existing pipe (which should fail, as the pipe does not exist yet). First problem, the connectToPipe method succeeds everytime, even when the pipe files PipeName_in and PipeName_out are missing in /tmp (I’m on MacOS).
If it cannot connect to an existing pipe, it will create it and wait for connections.
Plugin B is now instanciated, and takes the same algorithm (as they share this code).
Is it normal that the first plugin successfully connects to a pipe that does not exist? Is this method robust for creating/destroying/creating again pipes, or is there a need to reboot the system or something?
I also tried the opposite way:
- Plugin A tries to create the pipe. If it’s done successfully, it waits for connections. Otherwise, it tries to connect to the pipe as it might already exist, and createPipe failed for that reason. The call here is successful, because the pipe does not exist, this is normal.
- Plugin B does the same. The call to creation succeeds as well, even though the pipe files already exist and are used by the first plugin.
Actually, what would be great is a method DoesPipeExist, that only checks the presence of a pipe without trying to create it or connect to it.
(BTW: I’m using 1.53.104).
Edit: I just had a thought in mind, wouldn’t that be a problem that the two plugins are not actually processes on their own, but threads in the host’s common process? If that’s the case, I would need to fold back to the sockets solution.