Barebone local IPC within QtCore

kshegunov

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 the network module dependency for something so basic. Can someone suggest a better alternative (within the QtCore module, and preferably platform independent)?

Kind regards.

the_

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.

? Offline

Hi, maybe QSharedMemory?

kshegunov

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 QLocalSocket uses named pipe on windows and local domain socket on Linux. But since this is the only thing I want to use from the network module 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 select on 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 ...

? Offline

@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.

kshegunov

@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 SIGPOLL after 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 a QIODevice subclass 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.

? Offline

@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.

kshegunov

@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!