[Gdal-dev] C# Dataset not calling GDALClose()?

[Simon Perkins]

Could you explain this DLL locking thing? It would seem to be a sad day 
for shared libraries if only one executable could use them at a time! Or 
is it an issue that executables don't pick up recent changes to the 
shared library, preferring to use the OS cached version instead?

I think that OGRCleanupAll() only deletes the currently registered 
drivers, no? Does it actually unload the shared library? Is there an 
equivalent GDAL function, BTW, GDALDeregisterAll()?

Cheers,

Sy

Richard Matsunaga wrote:
> This would likely help me out a great deal, as well as anyone using GDAL
> inside of an ASP.NET web site.
>
> Cheers,
> Richard
>
>   
>> -----Original Message-----
>> From: gdal-dev-bounces at lists.maptools.org 
>>
>> Frank,
>>
>> OGRCleanupAll() is not exposed to SWIG right now. Should we 
>> add this function to the interface?
>>
>> Best regards,
>>
>> Tamas
>>
>>
>> 2007/7/11, Frank Warmerdam <warmerdam at pobox.com>:
>>     
>>> Richard Matsunaga wrote:
>>>       
>>>> Thanks Tamas, I didn't look deep enough to see what was 
>>>>         
>> happening in 
>>     
>>>> the C++ code for Dataset.
>>>>
>>>> My problem is that our application is an ASP.NET web site and as 
>>>> soon as a class instantiates a GDAL or OGR object, the 
>>>>         
>> GDAL dll gets 
>>     
>>>> locked and is only released after some long period of 
>>>>         
>> idle time or if iisreset is called.
>>     
>>>> This makes updating GDAL (or just republishing the entire 
>>>>         
>> website) a 
>>     
>>>> bit of a pain. I was initially worried that there may be a memory 
>>>> leak in there as well, but that seems to not be the case.
>>>>
>>>> The problem is easily reproduced using NUnit as well. Any 
>>>>         
>> test case 
>>     
>>>> that uses a GDAL resource will lock the GDAL dll as well.
>>>>
>>>> I just tried calling Ogr.RegisterAll() and it is the cause of the 
>>>> lock on the dll. There seems to be no way of releasing resources 
>>>> initialized by RegisterAll(). Not surprisingly, this behaviour is 
>>>> also flagged as a memory leak (albeit a small one) by 
>>>>         
>> DevPartner when using OGR in an application.
>>     
>>> Richard / Tamas,
>>>
>>> I'm not clear on what this "DLL locking" is all about, but at the C 
>>> level there is an OGRCleanupAll() function which will 
>>>       
>> deregister OGR 
>>     
>>> drivers as well as cleanup some other memory allocations.
>>>
>>> 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    | President OSGeo, 
>>>       
>> http://osgeo.org
>>     
>>>       
>> _______________________________________________
>> Gdal-dev mailing list
>> Gdal-dev at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/gdal-dev
>>     
>
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20070711/02f2d23c/attachment.html