Qt Forum

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

    Update: Forum Guidelines & Code of Conduct


    Qt World Summit: Early-Bird Tickets

    Unsolved QThread Blocking

    General and Desktop
    2
    4
    859
    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.
    • qt27
      qt27 last edited by

      I have a QMainWindow and want to use macros/scripts to automate things offered in the QMainWindow application. Among other things, this application uses a library that allows collecting data (in a thread) which also has a callback function when the data gathering is done. So it's something like this:

      class MyWindow : public QMainWindow()
      {
      RunMacro(Macro macro);
      static void CALLBACK MyCallback();
      private slots:
      OnGatherData();
      }

      The macro could be something like this:
      GatherData
      WaitForDataGatheringDone

      The above are executed by RunMacro. What I did to not block the GUI is creating a threat, passing it a pointer to MyWindow and in that thread I call RunMacro. My expectation was, that because RunMacro is called by a different thread MyWindow would not block. However, it does seem to block because my callback function to indicate that the data gathering is done gets never called. If that is indeed the case, then how would I solve it that I still can get that callback and not block MyWindow?

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

        @qt27
        Hi,
        This whole procedure sounds very suspicious and unnecessary, not to mention it probably is a disaster waiting to happen. What's the problem with connecting a few signals to some slots instead?

        The above are executed by RunMacro. What I did to not block the GUI is creating a threat, passing it a pointer to MyWindow and in that thread I call RunMacro.

        You just basically described what you should not do. For one the GUI classes are not even reentrant, not to mention thread-safe and while one could probably make an argument for synchronizing a few own methods it is ultimately unneeded.

        Kind regards.

        Read and abide by the Qt Code of Conduct

        1 Reply Last reply Reply Quote 0
        • qt27
          qt27 last edited by

          @qt27, thanks for the feedback. So the only other option I see then is creating a thread that sends signals for each macro/script step to the MyWindow application. I was kind of hoping to avoid this as it means creating a lot of pretty much duplicate signals (one from the GUI which gets arguments from an input window and one for the script/macro which gets arguments from the script/macro).

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

            @qt27

            So the only other option I see then is creating a thread that sends signals for each macro/script step to the MyWindow application.

            Rather a worker object that runs inside a separate thread, but yes, that approach sounds much better to me.

            I was kind of hoping to avoid this as it means creating a lot of pretty much duplicate signals (one from the GUI which gets arguments from an input window and one for the script/macro which gets arguments from the script/macro).

            I wouldn't call two signals-slot connections "a lot" and you skip the whole manual thread synchronization fiasco ... I should think this is good, isn't it?

            Kind regards.

            Read and abide by the Qt Code of Conduct

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