>> Me - still in the "hunch" mode - am still finding it odd that >> we need to use MT HVM to make QT not GPF. I perfectly believe >> your tests are correct and for you MT solved the problems, but >> we still don't see the deeper reason. >> >> For sure QT itself cannot require MT _HVM_, because it also >> works without Harbour. So the culprit could be HBQT, which >> makes use of, or requires HVM MT features to solve some >> problems on the wrapper level. It's also possible that HBQT >> has some explicit support for MT HVM mode, and this support >> accidentally broke ST builds. If true, it's IMO wrong, but >> beyond any personal opinions we should first of all document >> it, then possibly remove such MT HVM requirement and make it >> work in both modes without GPFs. >> > > HBQT _does not_ implements MT in its wrappers anyway. > "In HBQT", I assume that no Qt level MT support is implemented. > However I use mutexes in hbqt_slotc.cpp which is purely > on Harbour level.
I also couldn't find proof for any of this, but maybe some code cleaning could be done in current mutex support. F.e. mutex initialization and deinitialization, maybe more. > There could be one exception, if it has anything to do with > this issue, that there is a QThread() class wrappers in hbqtcore. > But QThread() call is nowhere made in any of the implementations. I don't think this has anything to do with our MT, unless .prg level code is called from these QT threads. Maybe the best would be drop support for QThread() as we already have our own, and it's not very easy to make two different MT interfaces live together. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
