Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Solved Barebone local IPC within QtCore

    General and Desktop
    ipc
    3
    8
    1940
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • kshegunov
      kshegunov Moderators last edited by

      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.

      Read and abide by the Qt Code of Conduct

      the_ 1 Reply Last reply Reply Quote 0
      • the_
        the_ @kshegunov last edited by

        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.

        -- No support in PM --

        kshegunov 1 Reply Last reply Reply Quote 0
        • ?
          A Former User last edited by

          Hi, maybe QSharedMemory?

          1 Reply Last reply Reply Quote 0
          • kshegunov
            kshegunov Moderators @the_ last edited by 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 ...

            Read and abide by the Qt Code of Conduct

            1 Reply Last reply Reply Quote 0
            • ?
              A Former User last edited by

              @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 1 Reply Last reply Reply Quote 0
              • kshegunov
                kshegunov Moderators @Guest last edited by 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.

                Read and abide by the Qt Code of Conduct

                ? 1 Reply Last reply Reply Quote 0
                • ?
                  A Former User @kshegunov last edited by

                  @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 1 Reply Last reply Reply Quote 0
                  • kshegunov
                    kshegunov Moderators @Guest last edited by 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!

                    Read and abide by the Qt Code of Conduct

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post