Hi
Viktor Szakáts wrote: > > 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. 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. Beyond that I am not very much informed about this aspect. Regards Pritpal Bedi -- View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13103--trunk-harbour-tp26627429p26683381.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
