1. 22 Aug, 2020 6 commits
    • Igor Kushnir's avatar
      GrepFindFilesThread: don't access globals in a non-main thread · 9015d80e
      Igor Kushnir authored
      As the now-removed comment stated, obtaining a project's file set from
      a non-main thread is not thread-safe.
      Let us collect all the necessary file sets once in the main thread, then
      use them in the worker thread.
    • Igor Kushnir's avatar
      GrepFindFilesThread: use d_ptr · ee1c4ec6
      Igor Kushnir authored
    • Igor Kushnir's avatar
    • Igor Kushnir's avatar
      GrepFindFilesThread: unite two related functions into a class · 6a48cea6
      Igor Kushnir authored
      Improve performance by passing the results variable by reference instead
      of returning lists and joining them.
    • Igor Kushnir's avatar
      GrepFindFilesThread: volatile => atomic · c3984b4e
      Igor Kushnir authored
      volatile is not suitable for thread synchronization in C++.
      Reorder GrepFindFilesThread's data members to reduce the size of this
    • Igor Kushnir's avatar
      Clarify when GrepFindFilesThread::files() may be called · 9097df6f
      Igor Kushnir authored
      Calling this function concurrently with GrepFindFilesThread::run() would
      be a data race. Fortunately, it is called only in
      GrepJob::slotFindFinished(), which is connected to
      Although I could not find this spelled out in Qt documentation, I think
      it is safe to access shared data without locking in a slot connected to
      QThread::finished(). It looks like the process of sending a signal from
      one thread and delivering it to a slot in another thread employs
      acquire and release semantics. The QThread::finished() documentation
      specifies that "This signal is emitted from the associated thread right
      before it finishes executing" unless "the associated thread was
      terminated using terminate()". My examination of relevant Qt 5.15 code
      revealed that:
        1) QThread::finished() signal is emitted after QThread::run() returns;
        2) before passing the signal to the receiver's thread, the sender's
           thread locks receiver->d_func()->threadData->postEventList.mutex in
        3) the receiver's thread locks the same mutex in
           QCoreApplicationPrivate::sendPostedEvents() before calling the
           connected slot.
      Eliminate an unnecessary copying in files() to improve performance and
      rename the member function to extractFiles() to match its new semantics.
  2. 18 Aug, 2020 1 commit
    • Igor Kushnir's avatar
      Remove unneeded uses of 'volatile' · 1d059dee
      Igor Kushnir authored
      I have analyzed the current code and the commits that introduced these
      'volatile' uses. Nothing seems even close to actually warrant volatile.
      I can think of 3 reasons why it was introduced in the first place:
        1. (most likely) temporary debugging/testing use that became permanent
           by oversight;
        2. some esoteric compiler/optimizer bug workaround (this hypothetical
           bug is highly unlikely to have survived for more than 10 years to
           remain in GCC);
        3. a way to work around / hide a bug in the code itself (unlikely;
           this would be an unreliable fix that could break with any compiler
           update or a different compiler).
      'volatile' is used very sparingly in KDevelop code because it is very
      rarely useful in application code. See also
      for valid 'volatile' use cases.
      test_codecompletion, test_duchain and test_embeddedfreetree still pass
      with these changes.
  3. 17 Aug, 2020 1 commit
  4. 16 Aug, 2020 6 commits
  5. 14 Aug, 2020 10 commits
  6. 12 Aug, 2020 3 commits
  7. 06 Aug, 2020 6 commits
  8. 01 Aug, 2020 2 commits
  9. 30 Jul, 2020 2 commits
  10. 23 Jul, 2020 2 commits
  11. 21 Jul, 2020 1 commit