[QGIS-Developer] Load a QgsMeshLayer within a QgsTask... different Threads?
Richard Duivenvoorde
rdmailings at duif.net
Fri Feb 10 05:22:23 PST 2023
Thanks Nyall,
I got it working with that trick, that is: I do not see any warnings anymore...
The place where you put moveToThread is crucial, AND I had to create the QgsMeshLayer WITHOUT default style:
options = QgsMeshLayer.LayerOptions()
options.loadDefaultStyle = False
self.layer = QgsMeshLayer(self.netcdf_file, 'PythonLoadedMeshLayer', 'mdal', options)
Because apparently creating the defaultstyle (in the layer constructor) tries to contact the other thread:
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsProject::fileName() const+0x267)[0x7fc592f1af2f]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadNamedProperty(QString const&, QgsMapLayer::PropertyType, bool&, QFlags<QgsMapLayer::StyleCategory>)+0x752)[0x7fc592a215c0]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadNamedStyle(QString const&, bool&, QFlags<QgsMapLayer::StyleCategory>)+0x2b1)[0x7fc592a20b8f]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadDefaultStyle(bool&)+0x2dc)[0x7fc592a1f6ec]
Not sure, but I think it would be good/nice if that would not be the case?
Another observation: if I use some Processing Scripts (not sure which one, either join-by-attribute or select-by-location), these are throwing the exact same warning about running something from another thread.
Anyway: thanks for the hint/tip!!!
Regards,
Richard Duivenvoorde
On 2/9/23 09:26, Nyall Dawson wrote:
>
>
> On Thu, 9 Feb 2023, 6:18 pm Richard Duivenvoorde via QGIS-Developer, <qgis-developer at lists.osgeo.org <mailto:qgis-developer at lists.osgeo.org>> wrote:
>
> Ok after reading https://docs.qgis.org/3.28/en/docs/pyqgis_developer_cookbook/tasks.html <https://docs.qgis.org/3.28/en/docs/pyqgis_developer_cookbook/tasks.html> again, reading the warning:
>
> "Any background task (regardless of how it is created) must NEVER use any QObject that lives on the main thread, such as accessing QgsVectorLayer, QgsProject or perform any GUI based operations like creating new widgets or interacting with existing widgets. Qt widgets must only be accessed or modified from the main thread. Data that is used in a task must be copied before the task is started. Attempting to use them from background threads will result in crashes."
>
>
> One thing you can do:
>
> From the thread which owns the object, when you've finished using that object in the thread, call object.moveToThread(QgsApplication.instance().thread())
>
> You're allowed to push objects which belong to the current thread to another thread, but never allowed to pull objects which belong to another thread over to the current thread.
>
> Nyall
>
>
>
> Seems to make it pretty clear :-(
>
> Before rereading that, I even tried to pass a QgsMeshLayer-'reference' to the QgsTask, but that did not work either.
>
> I think I must conclude that I just have to wait for the load... :-)
>
> Regards,
>
> Richard Duivenvoorde
>
>
>
> On 2/8/23 21:40, Richard Duivenvoorde via QGIS-Developer wrote:
> > Hi,
> >
> > Having to juggle with rather large/long loading netcdf files, I thought to off load the loading to a QgsTask, so while the netcdf was loaded user could do other things...
> >
> > But I get "...is run from a different thread than the object lives in ..." warnings.
> >
> > In short:
> >
> > def run(self) -> bool:
> > log.info <http://log.info>(f'LOADING... {self.netcdf_file}')
> > try:
> > self.layer = QgsMeshLayer(self.netcdf_file, 'PythonLoadedMeshLayer', 'mdal')
> > ....
> >
> > BUT: while it looks like all is fine, I get a Qt warning in my messages, and on my terminal I get:
> >
> > [INFO] (Dummy-1 ) LOADING... /tmp/kees/aoi/aoi1/areaOfInterest1.nc
> > Warning: fileName (/home/richard/git/qgis/src/core/project/qgsproject.cpp:812) is run from a different thread than the object lives in [0x5593004f1aa0 vs 0x5592ff7e6440]
> > Stacktrace (piped through c++filt):
> > /home/richard/bin/qgis_/master/debug/bin/qgis(+0xe26a)[0x5592fe9ba26a]
> > /home/richard/bin/qgis_/master/debug/bin/qgis(+0xea29)[0x5592fe9baa29]
> > /lib/x86_64-linux-gnu/libQt5Core.so.5(+0xc3b50)[0x7fc594ec3b50]
> > /lib/x86_64-linux-gnu/libQt5Core.so.5(qt_message_output(QtMsgType, QMessageLogContext const&, QString const&)+0xd)[0x7fc594ec50fd]
> > /lib/x86_64-linux-gnu/libQt5Core.so.5(QDebug::~QDebug()+0x68)[0x7fc594fc6fa8]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsProject::fileName() const+0x267)[0x7fc592f1af2f]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadNamedProperty(QString const&, QgsMapLayer::PropertyType, bool&, QFlags<QgsMapLayer::StyleCategory>)+0x752)[0x7fc592a215c0]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadNamedStyle(QString const&, bool&, QFlags<QgsMapLayer::StyleCategory>)+0x2b1)[0x7fc592a20b8f]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadDefaultStyle(bool&)+0x2dc)[0x7fc592a1f6ec]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMeshLayer::loadDefaultStyle(bool&)+0x685)[0x7fc5930a84bb]
> > /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMeshLayer::QgsMeshLayer(QString const&, QString const&, QString const&, QgsMeshLayer::LayerOptions const&)+0x2b9)[0x7fc5930a5ab1]
> > /home/richard/bin/qgis_/master/debug/share/qgis/python/qgis/_core.so(sipQgsMeshLayer::sipQgsMeshLayer(QString const&, QString const&, QString const&, QgsMeshLayer::LayerOptions const&)+0x3b)[0x7fc43040b9c7]
> > /home/richard/bin/qgis_/master/debug/share/qgis/python/qgis/_core.so(+0x121a0bc)[0x7fc43041a0bc]
> > /usr/lib/python3/dist-packages/PyQt5/sip.cpython-311-x86_64-linux-gnu.so <http://sip.cpython-311-x86_64-linux-gnu.so>(+0x19f60)[0x7fc4dc271f60]
> > /lib/x86_64-linux-gnu/libpython3.11.so.1.0(+0x1e02fe)[0x7fc47a5e02fe]
> > /lib/x86_64-linux-gnu/libpython3.11.so.1.0(_PyObject_MakeTpCall+0x7d)[0x7fc47a57baed]
> > /lib/x86_64-linux-gnu/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x4a63)[0x7fc47a509c63]
> > /lib/x86_64-linux-gnu/libpython3.11.so.1.0(+0x26a6da)[0x7fc47a66a6da]
> > /lib/x86_64-linux-gnu/libpython3.11.so.1.0(+0x17f30c)[0x7fc47a57f30c]
> > /usr/lib/python3/dist-packages/PyQt5/sip.cpython-311-x86_64-linux-gnu.so <http://sip.cpython-311-x86_64-linux-gnu.so>(+0x1196c)[0x7fc4dc26996c]
> > [INFO] (MainThread) finished OK
> >
> > My Questions:
> > - should I NOT do this?
> > - or is the loading/construction of a QgsMeshLayer having pointers to places it should not?
> >
> > (mmm loading a QgsVectorLayer (shape via ogr) also results in about the same warnings...
> > so next question: is there another way to load these large netcdf's without blocking QGIS ?)
> >
> > Thanks for any info.
> >
> > Regards,
> >
> > Richard Duivenvoorde
> > _______________________________________________
> > QGIS-Developer mailing list
> > QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>
More information about the QGIS-Developer
mailing list