[gdal-dev] GDALDataset blocks in different thread

[James Meyer]

Oh okay. Thanks!

All the while I thought I was doing something wrong.
I'm assuming the fix won't be reflected in the version that is available 
from the Ubuntu repositories, right?
In other words I will need to build GDAL from source then?

Regards

James

On 16/09/2010 21:29, Even Rouault wrote:
> James,
>
> ok, I confirm the bug. This was indeed specific to the new implementation of the
> PCIDSK driver that came in 1.7.0.
>
> See http://trac.osgeo.org/gdal/ticket/3755 for the fix
>
> Le jeudi 16 septembre 2010 20:57:51, James Meyer a écrit :
>    
>> Hi Even
>>
>> Thanks for the reply. I ran your code and it doesn't block with your
>> sample tiff file.
>> It blocks with any .pix files (driver: PCIDSK Database File) with the
>> output being:
>>
>> *********************
>> in thread
>> finished
>> ********************/
>>
>> /I am running Ubuntu 10.04 and have GDAL 1.7 on my system installed
>> through the package manager.
>> CPL_MULTIPROC_PTHREAD is 1.
>>
>> When I debug the program with gdb and reach the line that blocks, gdb
>> blocks along with the line. I also can't step into the call to
>> GDALChecksumImage.
>> Of course I might be debugging it wrong.
>>
>> Any ideas?
>>
>> On 16/09/2010 19:27, Even Rouault wrote:
>>      
>>> James,
>>>
>>> what you see is a bit surprising...
>>>
>>> Do you build GDAL by yourself or use a packaged version ? If you build it
>>> yourself, you explicitely need to specify --with-threads at ./configure
>>> time (unless you use the latest trunk version where it is now the
>>> default). In port/cpl_multiproc.h, you can see #define
>>> CPL_MULTIPROC_PTHREAD 1 if everything works. If you have only the .so,
>>> you can for example try using the CPLCreateThread() method. If it
>>> returns -1, then you have the stub implementation.
>>>
>>> Could you try compiling and running the following code that is an attempt
>>> to have a minimum scenario that reproduces what you descrbe ?
>>>
>>> ****************************************
>>>
>>> #include<gdal.h>
>>> #include<gdal_alg.h>
>>> #include "cpl_multiproc.h"
>>>
>>> void my_thread(void* pData)
>>> {
>>>
>>>       GDALDatasetH hDS;
>>>       int checksum;
>>>       hDS = (GDALDatasetH)pData;
>>>
>>>       printf("in thread\n");
>>>       checksum = GDALChecksumImage(GDALGetRasterBand(hDS, 1), 0, 0, 20,
>>>       20); printf("checksum = %d\n", checksum);
>>>
>>> }
>>>
>>> int main(int argc, char* argv[])
>>> {
>>>
>>>       GDALDatasetH hDS;
>>>       GDALAllRegister();
>>>       hDS = GDALOpen("byte.tif", GA_ReadOnly);
>>>       CPLCreateThread(my_thread, hDS);
>>>       CPLSleep(2);
>>>       printf("finished\n");
>>>       return 0;
>>>
>>> }
>>>
>>> ****************************************
>>>
>>> It works fine for me. The byte.tif is available at
>>> http://trac.osgeo.org/gdal/export/20628/trunk/autotest/gcore/data/byte.ti
>>> f
>>>
>>> Otherwise, which OS are you using ?  which GDAL version ? Which GDAL
>>> driver is used by your dataset ? etc etc ? If you run it under gdb, what
>>> is the stack trace when it is blocked ?
>>>
>>> Even
>>>
>>> Le jeudi 16 septembre 2010 10:23:27, James Meyer a écrit :
>>>        
>>>> Hi
>>>>
>>>> I am opening a GDALDataset in my main thread which I then pass to a
>>>> second thread for processing. Only the second thread accesses the
>>>> dataset.
>>>>
>>>> As soon as the thread makes a call to GDALRasterBand::RasterIO() the
>>>> thread blocks indefinitely.
>>>>
>>>> Could you please explain to me why this is happening?
>>>>
>>>> Also, how do I check whether my build of GDAL was built with the
>>>> --with-threads option enabled?
>>>>
>>>> Thanks
>>>>
>>>> James
>>>> _______________________________________________
>>>> gdal-dev mailing list
>>>> gdal-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>>>          
>