Barebone local IPC within QtCore
-
Hello,
For the deamon I'm working on I need to have some very basic IPC (sending simple commands to the deamonized process). I was first thinking of opening a local server/local socket but I'm reluctant to add thenetworkmodule dependency for something so basic. Can someone suggest a better alternative (within the QtCore module, and preferably platform independent)?Kind regards.
-
Hi @kshegunov
If both processes are written by you and run on the same machine you could use (un)named pipes or semaphore for IPC.
-
Hi, maybe QSharedMemory?
-
Hello,
@the_ said:
If both processes are written by you and run on the same machine you could use (un)named pipes or semaphore for IPC.
They are, they're actually the same process forked. The thing is
QLocalSocketuses named pipe on windows and local domain socket on Linux. But since this is the only thing I want to use from thenetworkmodule it seems an overkill to load some MB's of a binary with hundreds of symbols just for it. I don't believe Qt directly exposes the pipes from the core module, though, am I in error?@Wieland
Hi, maybe QSharedMemory?
This was what I was thinking about initially, beside using a file. The only thing that I see as a drawback is how to notify each process that there's a piece of data pending. It seems I either have to thread the shared memory segment code and poll on it, or use
selecton a file, which would defeat the purpose of having shared memory in the first place. Maybe using a system semaphore is an alternative to polling, however if the system kills the daemon ... well, you know how it is with global resources ... -
@kshegunov said:
The only thing that I see as a drawback is how to notify each process that there's a piece of data pending.
You could use good old posix signals for that.
-
@Wieland
You could use good old posix signals for that.
I am already capturing the interrupt, termination and segmentation fault signals. I suppose I could send the
SIGPOLLafter writing data to the memory segment, but it is really strange Qt doesn't provide a named pipe in the core module out of the box. Another alternative to signalling would be to actually sit down and write a FIFO wrapper in aQIODevicesubclass for example, which I'm currently considering.Thanks for the feedback guys, it's been helpful and enlightening. I will mark this as solved, but if anyone has more/other suggestions, I'd gladly welcome them.
Kind regards.
-
@kshegunov said:
but it is really strange Qt doesn't provide a named pipe in the core module out of the box
QLocalSocket uses named pipes on Windows. Speaking of Linux, all these IPCs are more or less obsolete with the advent of kdbus.
-
@Wieland
QLocalSocket uses named pipes on Windows.
Sure, I acknowledged that in my first post.
Speaking of Linux, all these IPCs are more or less obsolete with the advent of kdbus.
Maybe, however there are some issues with that. Kdbus is in the newest kernels only and not all distributions provide them (especially such as the stable flavor of Debian and other OS-es focused on longer release cycle/long-term support). The d-bus daemon is usually present, but not always, and as I recently found out (@SGaist pointed me to it) it's coming to Windows as a service. However without a full blown support from the core OS it may or may not prove a reasonable alternative. On the other hand, pipes are as old as computers themselves and run fine on pretty much any platform, have small overhead and are flexible solution to many such small-ish problems as mine.
Do note, also, that from time to time a new technology claims that a more mature one will simply die out, however, it doesn't much seem to be the case. Java was supposed to "kill" C++, well it didn't happen. QML was supposed to replace the widgets - I personally find QML distasteful and still stick to the old-school C++ way and many others it seems.
Anyway, don't take this as a rant, I'm just sharing a few observations. ;)
Cheers!
