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,
<[email protected] <mailto:[email protected]>> 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
> [email protected] <mailto:[email protected]>
> 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
[email protected] <mailto:[email protected]>
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
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
