4 Feb
2019
4 Feb
'19
5:09 a.m.
On Sunday 03 of February 2019 14:27:18 Mike Bird wrote:
On Sun February 3 2019 03:55:00 Slávek Banko wrote:
As far as I know, all the mutex code is within the MAKE_TQSTRING_THREAD_SAFE
condition, which is at the beginning of the file with the following comment:
// WARNING
// When MAKE_TQSTRING_THREAD_SAFE is defined, overall TQt3 performance suffers badly!
// TQString is thread unsafe in many other areas; perhaps this option is not even useful?
// #define MAKE_TQSTRING_THREAD_SAFE 1
Hello to all programmers,
please give your attention and share your opinion to the proposed
patch for TQt3. For a detailed description of the problem, see the
pull-request:
https://mirror.git.trinitydesktop.org/gitea/TDE/tqt3/pulls/6
Hi Slavek,
Sorry I don't have time to fully understand this code. All the levels
of nested classes and shallow copying made my head spin but I don't
see any obvious problems there. So just a couple of quick thoughts:
(1) I see a mutex and a lot of code that is not - at least to me -
obviously thread safe.
(2) Having the cstring in the TQStringData but the
assignments to
ctring in the TQString methods seems awkward but may be the best
solution available.
TQStringData is an internal data structure for TQString. That's why
there's nothing awkward about manipulating its items from TQString.
--Mike
Cheers
--
Slávek