I am planning to write some software that will control several peripherals: PCI motion control card, RS232 signal generator, PCI data acquisition, two coolings units through RS232, and some polling of files on a network folder.
I have written similar software in the past, whereby each of the aforementioned peripherals where in their process, and IPC was used in a server/client method. Each process acted as a server listening for commands through its channel, with one central controller as the client.
What would be the advantages/disadvantages of doing this over, but with one process and several individual threads, each with its own channel?
modularity is your friend. I would go with process for something like that. There are lots of advantages:
Modularity (easier to have more then one persone work on the project)
Easier to debug
Robustess (if one thread dies it kill the whole process)
You would gain very little performance by going with thread. You would need some sort of synch method any, which message passing handles for you.
Each process can have it’s own console/pterm making it easier to add print statement, otherwise all the thread prints to the same console which can create havoc
A bug in a thread can crash another thread which makes finding the bug nightmarish.
Well you can still do it with thread if you want. Just write your own “printf/cout library” and depending on the thread name or thread id forward the output to a different console. As you can see it`s more trouble then what little avantage you may gain ( in your perticular case)
Ahhh! That is the kind of thing you can use slogger for … don’t write your own library to do it!
That said, my vote is still with Mario on using two processes. If the entities are distinct, keep them separately encapsulated
right down to the source.