> Yes, requests must be somehow assigned to layers/providers so that > progress may be emitted from the right place. It could be maybe done > using GDALDatasetH pointer? Just another hack.
I've no ideal solution for this. Your suggestion could be indeed a possibility : adding 2 methods GDALDatasetSetUserData() & GDALDatasetGetUserData() and the user data being passed to the custom http fetcher if it is defined. Except that I think that in the Open() method of the WCS driver, there are already HTTP requests done to determine some characteristics of the dataset, so that is not practical since the dataset handle isn't yet known at that time. Would need more thinking. > > In theory, we are going to use threads, which could complicate it even > more. It is not yet clear to me if QgsRasterDataProvider::readBlock of > an instance is also going to be called from multiple threads > simultaneously? That can be a problem. And it isn't specific to the WCS driver. It is generally not safe to access the *same* dataset handle concurrently from multiple threads with most GDAL drivers, because the XXXDataset or XXXRasterBand classes may have state variables that aren't protected against concurrent access. Looking a bit at the WCS driver, I can see that the osResultFilename and pabySavedDataBuffer member variables would certainly not appreciate concurrent access on the same dataset handle. But looking at how they are used, they is no need to make them persist between different calls to the IReadBlock() method. So they could be easily made local variables passed to the GDALOpenResult() and FlushMemoryResult() methods. But reading your later email where you mention that the native QGIS WCS driver is almost there, there's probably no need to dig further into this. Thanks for having shared your thoughts, Even _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
