[Gdal-dev] GDAL, ECW, and COM

Frank Warmerdam fwarmerdam at gmail.com
Fri Apr 1 17:46:05 EST 2005

On Apr 1, 2005 5:10 PM, Peng Gao <pgao at esri.com> wrote:
> I wrote a new GDAL dataset whose implementation uses some COM objects.
> When I do a CreateCopy() using my dataset as input, it works for most
> formats except ECW. The error is that COM objects can not be cocreated
> because CoInitialize() is not called on the thread. The following is
> the call stack (Windows) when the error occurred. It looks like a
> different thread from the main thread where GDALDriver::CreateCopy() is
> invoked.
> If this is true, can the compressor thread be enclosed in CoInitialize()
> and CoUninitialize()?


I'm am not too savvy on COM or multi-threading issues, so you may need
to spell a few things out for me. 

First, my understanding is that the ECW driver is multi-threaded, and 
uses seperate working threads when compressing.  Furthermore, these
worker threads end up "calling back" to get the data source the source
dataset.  So the IO calls on the source file will happen in a thread other
than the main one used for GDAL. 

I gather it is this being called from a different thread that is causing
you problems? 

>From the GDAL level I don't really have any access inside the ECW
compressor thread except for in the callback.  I suppose I could add
something to do a coinitialize in there on the first callback, but it 
really seems like this is an issue with the COM based driver.  Couldn't
it do a CoInitialize() internally in any function that gets called by a new

Doing the uninitialize would be quite a bit tricker since there is no
easy way to know when the last call from the thread has been made.

Darn, I hate multi-threading.

Best regards,
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

More information about the Gdal-dev mailing list