Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QTimer

QTimer

Scheduled Pinned Locked Moved General and Desktop
10 Posts 3 Posters 3.5k Views 1 Watching
  • 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.
  • B Offline
    B Offline
    Brandon
    wrote on last edited by
    #1

    Here's the question. Let's say that I have a single threaded program. I create a QTimer to go off every 10 seconds. The timer calls a method which takes a full minute to execute (longer than the period of the timer). What will happen? Thanks.

    1 Reply Last reply
    0
    • sierdzioS Offline
      sierdzioS Offline
      sierdzio
      Moderators
      wrote on last edited by
      #2

      It should work correctly, assuming you write the code well. Timers use the unix time to get their bearing, this does not depend on the CPU load, AFAIK (but there are more accurate methods that do).

      You will have to keep calliing qApp->processEvents() anyway to prevent app freezing and keep user experience in check. This sounds like a good situation to use QThread :)

      (Z(:^

      1 Reply Last reply
      0
      • B Offline
        B Offline
        Brandon
        wrote on last edited by
        #3

        If the single thread program is tied up for a full minute executing each time, how can the QTimer make the call every 10 seconds? Is QTimer inherently asynchronous, even in a single threaded program? If the timer can go off despite its previous calls still processing, will there be six copies of the called function running? Should I put mutexes on the resources?

        1 Reply Last reply
        0
        • sierdzioS Offline
          sierdzioS Offline
          sierdzio
          Moderators
          wrote on last edited by
          #4

          Hey, sorry, I somehow read it as "10 minutes" instead of seconds. Then it all depends on whether you will use ::processEvents() or not. Best solution: test it, I don't think I've ever been in a situation like this, so I can't be certain.

          (Z(:^

          1 Reply Last reply
          0
          • B Offline
            B Offline
            Brandon
            wrote on last edited by
            #5

            I can tell you that I'm not using processEvents(). I'm pretty much a Qt amateur. I'm worried that if a timer calls a method multiple time before it finishes executing, then I will have to make the resources thread safe even though it is nominally a single thread program.

            1 Reply Last reply
            0
            • sierdzioS Offline
              sierdzioS Offline
              sierdzio
              Moderators
              wrote on last edited by
              #6

              OK, then I think you are safe (just be careful as your app will freeze for that 1 minute of processing), but better check yourself. And post the results here, please, I'm curious.

              (Z(:^

              1 Reply Last reply
              0
              • B Offline
                B Offline
                Brandon
                wrote on last edited by
                #7

                Actually, I'm exaggerating the times in order to give a clear example. The timer actually goes off every second, and the processing probably takes a second or two. If I do see a problem occur, I will post it here, but this is for a rather obscure feature of the application, so it doesn't get exercised very much. I'm just thinking like a programmer and trying to cover all the bases. Thanks a lot for your ideas.

                1 Reply Last reply
                0
                • A Offline
                  A Offline
                  andre
                  wrote on last edited by
                  #8

                  Using processEvents() is, IMHO, not something to advocate lightly. It is a dangerous tool, that can have very interesting consequences like the code entering the function you called it from a second time unless you're quite careful.

                  As for the timer events: I think they'll get lost. QTimer is not something that magically runs async from the rest of the application. It relies on the eventhandling from the eventloop to work.

                  1 Reply Last reply
                  0
                  • B Offline
                    B Offline
                    Brandon
                    wrote on last edited by
                    #9

                    Actually, if so, that frees me from the need to take all sorts of precautions to avoid resource collisions, e.g. mutexes, so I hope you're right.

                    1 Reply Last reply
                    0
                    • A Offline
                      A Offline
                      andre
                      wrote on last edited by
                      #10

                      In any case: the code handing the result of the timer will not be entered multiple times (as long as you avoid using processEvents()). So, there is no need to protect that section of code.

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved