| Trolltech Home | Qt-jambi-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 1 | |
Hi folks! Since beta1 all methods seem to call com.trolltech.qt.QtJambiInternal.threadCheck() before they are actually executed. Good approach, this way illegal thread accesses are almost gone, but is that really also needed for getters? I mean, why would e.g. QWidget.size() need to be checked that way, size() doesn't change the state of the QWidget, same counts for other getters. And if that's really actually needed wasn't it fine to have something like QCoreApplication.invokeAndWait(Runnable) to be able to use getters from everywhere with a small amount of extra code (invokeLater() already requires some waiting mechanism)? Or is that already there in some manner and i just didn't find it yet? With best regards and the wish to be enlightened :) Georg Schild
Georg Schild wrote: > Hi folks! > > Since beta1 all methods seem to call > com.trolltech.qt.QtJambiInternal.threadCheck() before they are actually > executed. Good approach, this way illegal thread accesses are almost > gone, but is that really also needed for getters? I mean, why would e.g. > QWidget.size() need to be checked that way, size() doesn't change the > state of the QWidget, same counts for other getters. Truth is you don't really know that. size() could be lazily calculated based on layout metrics so it could do lots of things behind the scenes. This is the case for many get'ers. If your worry here is performance of the extra call this is a safty option that can be disabled by executing the vm with the parameter -Dcom.trolltech.qt.thread-check=false > And if that's > really actually needed wasn't it fine to have something like > QCoreApplication.invokeAndWait(Runnable) to be able to use getters from > everywhere with a small amount of extra code There is no global mutex in Qt unfortunatly, so there is no way to block all threads while executing the statement for this particular object. > (invokeLater() already > requires some waiting mechanism)? Invoke later executes in the applications main thread(). > Or is that already there in some manner and i just didn't find it yet? Unfortunatly not, and I don't see that we can add it easily either, but I'll about it. best regards, Gunnar
On Wednesday 07 February 2007 19:58, Gunnar Sletta wrote: > Truth is you don't really know that. size() could be lazily calculated > based on layout metrics so it could do lots of things behind the scenes. > This is the case for many get'ers. That sounds weird... In C++ most getters are const. Which means they can not even change the widget even if you wanted to. More, if the getter were to create some objects or access other objects then the threadCheck() would fail for them even if you don't have the check in the getter itself. -- [ signature omitted ]
Attachment:
pgprEYkY9knTT.pgp
Description: PGP signature
Thomas Zander wrote: > On Wednesday 07 February 2007 19:58, Gunnar Sletta wrote: > >>Truth is you don't really know that. size() could be lazily calculated >>based on layout metrics so it could do lots of things behind the scenes. >>This is the case for many get'ers. > > > That sounds weird... > > In C++ most getters are const. Which means they can not even change the widget > even if you wanted to. If you only knew how often the const is const_cast'ed away ;-) Even if this wasn't the case, reading a value from a getter in thread A while its being updated in thread B would still cause problems so. > More, if the getter were to create some objects or access other objects then > the threadCheck() would fail for them even if you don't have the check in the > getter itself. Only if this propegates back to java which it rarely does. Its mostly updating the internal cache structures etc. Hidden from even the public C++ api. - Gunnar
Gunnar Sletta schrieb: > If your worry here is performance of the extra call this is a safty > option that can be disabled by executing the vm with the parameter > -Dcom.trolltech.qt.thread-check=false Ok, that switch is probably a good solution for now, hopefully it doesn't get removed in future versions ;). > Invoke later executes in the applications main thread(). > >> Or is that already there in some manner and i just didn't find it yet? > > Unfortunatly not, and I don't see that we can add it easily either, > but I'll about it. Would be fine to have, other toolkits offer similar things (Swing, SWT) although i really don't know the Qt internals ;) best regards Georg Schild