[Gdal-dev] GDAL, ECW, and COM
MChapman at sanz.com
Fri Apr 1 19:14:37 EST 2005
Anytime you create a new thread on windows using ATL (COM) you need to
do something like this:
unsigned long WINAPI ThreadProc(void* p)
CParseServer *pParseServer = (CParseServer*) p;
ParseProcessor.m_nIdleTime = pParseServer->m_nIdleTime;
ParseProcessor.m_sEmailTo = pParseServer->m_sEmailTo;
// handle it
From: gdal-dev-bounces at xserve.flids.com
[mailto:gdal-dev-bounces at xserve.flids.com] On Behalf Of Frank Warmerdam
Sent: Friday, April 01, 2005 3:46 PM
To: Peng Gao
Cc: GDAL Dev
Subject: Re: [Gdal-dev] GDAL, ECW, and COM
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
>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
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.
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
Gdal-dev mailing list
Gdal-dev at xserve.flids.com
More information about the Gdal-dev