Easiest way to implement IPC with serial port process

[Adar70]

Hello. I'm tasked with talking to a device through a serial port. As only one process can have access to the port, a special subprocess needs to be created for it. At any point a different process on the PC can send something to that serial port process, to communicate with the device, as well as the device can send some data through the serial port. That's why I need to listen for both at the same time, though whatever the device sends has priority.

What would be the best way to implement inter-process communication here? I know I'm going to use QSerialPort for the serial port. I tried stock python stdin and stdout, but it's rough without a convinient readyRead() signal the QIODevice presents. I was thinking about using QTcpSocket.

[JonB]

@Adar70
I know nothing about whether any of the serial stuff is advisable or possible. But yes QTcpSocket would probably be better than stdin/out etc. Qt also has QLocalSocket/QLocalServer , if you're Windows that's a named pipe

[Adar70]

Isn't there anything simpler maybe? It's not a big app. I have one main process, a subprocess that tells the device what to do, and the serial port process.

[SGaist]

Hi,

First thing: why three different processes ?
Do you have ready made applications that you have to use ?
In any case, Qt being asynchronous, you should leverage that part first before splitting in multiple sub processes.

[Adar70]

@SGaist

First thing: why three different processes ?

The first process is the main one, hosting the GUI, among other stuff connected to the mediator. Second is an external program that the app would have to run. Both the GUI process and the external program need to access a serial port. Since only one single process can do that, the serial port needs to have its own managing process, hence three processes. Though since it's getting complex, I'd have to also put up a server.

Do you have ready made applications that you have to use ?

I don't know what you mean. Yeah I have written the GUI app. I'll also write the library for the external program. I'm the sole developer and manager of the project.

In any case, Qt being asynchronous, you should leverage that part first before splitting in multiple sub processes.

Oh, I'd love to do that, but figuring out from the docs what is or isn't asynchronous is confusing.

[JonB]

@Adar70 said in Easiest way to implement IPC with serial port process:

Both the GUI process and the external program need to access a serial port. Since only one single process can do that, the serial port needs to have its own managing process, hence three processes

From this description, in principle why can't, say, the GUI process also be the serial port broker? Why do you need a separate, third process for that?

You need the external program if you are saying that is third-party by definition. If it's your own code then again do you need it in a separate process as opposed to functionality within your Qt UI process?

Qt I/O for QSerialPort is asynchronous, working with signals & slots via a main event loop. So the GUI is not blocked while serial port operations are being performed.

Isn't there anything simpler maybe?

Simpler than what? If you have to do IPC then you have to do IPC. That tends to mean stdin/out (you have found not suitable), shared memory (wouldn't use that for preference, unless maybe speed is absolutely critical or data is large, but you have to handle contentions) or TCP/sockets/named pipes (obvious choice here).

[Adar70]

@JonB

From this description, in principle why can't, say, the GUI process also be the serial port broker? Why do you need a separate, third process for that?

That's true, it can be done. I was first hesitant because I thought it might slow things down too much, but I see that the complexity is not worth it.

[SGaist]

An old developer advice: don't think about performance, benchmark. That's the only way to know.

Keep your business logic nicely separated from your GUI so if really becomes a bottleneck, then you can consider using something like threads but really only after you proved that the added complexity is worth it.

From your description you seem to have two different logical units requiring access to the serial port. This does not warrant the creation of two processes.

[Adar70]

@SGaist @JonB Thank you both.