CloseDatabase hanging on 64 bit Linux when same File Geodatabase opened twice

[SimonWood]

Hi,

Came across what looks to be a linux 64-bit specific bug when opening the same gdb twice (using different FileGDBAPI::Geodatabase instances) simultaneously - the CloseDatabase call is never returning.

Ive attached some code to reproduce this (just need to modify the path to the gdb to point to something valid).

On the same linux rhel6 (64 bit) machine, this code:
* works fine when built as 32-bit
* hangs forever on the first CloseDatabase call (debugger shows it is stuck in FileGDBAPI::Geodatabase::CloseGeodatabase() ), when built as 64-bit.

Its based on one of the samples, so Im just using "make" to build 64-bit and "make ARCH=32" to build 32-bit.. And Im using v1.3 of the API, but also happens with earlier versions.


I assume this is a fundamentally supported thing to do (?) - I can't see anything in the docs to the contrary..


Thanks,

Regards,
Simon

[DavidSousa]

The API does not use COM.  There are no COM objects, no STA, just C++ classes.  There is no use of thread local storage either.

The limitation on multi-threading is due to the use of LibXML by the API.  LibXML has global state and cannot be used concurrently by more than one thread per process.

There might be certain workflows that don't make any use of LibXML during processing.  In those cases, multi-threading might just work.  But even then, if an individual database or table was being accessed simultaneously by more than one thread it might lead to trouble.  It would be better to segregate access to tables to separate threads.

[DaveBrann]

Thanks again for the information.   It is very helpful.

In a post in the discussion, it was mentioned that FGDB code caches Geodatabase and Table objects and just reference count them if the same database and table are requested by an API user.   If that is true, then it seems like it would not be possible to segregate access to tables in separate threads.   Correct?  

Thanks,
Dave

[DavidSousa]

It would mean using a separate thread for each table.  That is under your control.

I am not sure this would work, but it's much more likely to work this way than it would if the same table was accessed by more than one thread.

This also assumes that whatever processing is happening is not making any use of LibXML in more than one thread at a time.  The main use of LibXML is when the API is doing anything related to schema, e.g., creating a new table, describing an existing table, adding or removing a column, etc.  All of those operations involve the use of XML.  But XML usage in minimized if all you are doing is opening a table and getting its rows.