bruns added a comment.

  In D13814#290556 <https://phabricator.kde.org/D13814#290556>, @markg wrote:
  
  > Is there even a need to have n QCollator objects?
  >  I'm talking about a QCollator _within_ a given view. Each view could 
obviously have it's own collator due to different view settings.
  
  
  Strictly speaking you need one collator per thread (it is reentrant (save the 
bug), but not thread-safe). As long as the collator objects are not modified, 
each one is just the d-pointer, as QCollator is CoW.
  
  Copying a clean QCollator is cheap. Default-constructing one and modifying it 
is expensive - each one has to be initialize the underlying ICU (actually, this 
happens twice for each one, once on construction, once after the 
m_collator.setFoo(...) calls).
  
  Using a const reference, as done here, is even slightly cheaper. But doing so 
is also undefined behaviour - QCollator is reentrant, but not thread-safe. We 
get away with it by using the forced initialization, which avoids the UB (UB 
only happens when the QCollator is dirty).
  
  When the fix in https://codereview.qt-project.org/#/c/234359/3//ALL,unified 
is applied, it is no longer necessary to force the `init()` under the premise 
each thread uses its own private collator object (which is implicitly shared).

REPOSITORY
  R318 Dolphin

REVISION DETAIL
  https://phabricator.kde.org/D13814

To: jtamate, #dolphin, #frameworks, markg, elvisangelaccio, bruns
Cc: elvisangelaccio, apol, bruns, markg, kfm-devel, spoorun, navarromorales, 
firef, andrebarros, emmanuelp

Reply via email to