[fdo-internals] SDF 3.0 FDO Provider Serious Memory Leak

[Badreddine Karoui]

Every provider publish its threading capability. The caller should check the provider threading support. Most providers including the SDF provider are per connection threaded which means you should not have two threads using the same connection at the same time. You still can pass objects created by one thread to an other thread but only one thread can use that object. MapGuide server is a good example of application that uses threads(a lot of them) and manage providers according to their threading capability.

Badreddine


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Carl Jokl
Sent: Tuesday, July 15, 2008 5:58 AM
To: fdo-internals at lists.osgeo.org
Subject: RE: [fdo-internals] SDF 3.0 FDO Provider Serious Memory Leak


So looking at thread safety in general. I have not used multithreaded FDO
manipulation. Judging by what I have seen so far I would think it risky.

I also don't know if any multi-threading is used by the native C++ code. I
did wonder if that could improve the performance of the PostGIS FDO driver
perhaps. Potentially one thread busy pulling raw data from the database (IO
Bound thread) with the other busy restructuring it into the FDO required
format (Processor bound thread). The next batch or raw data being loaded
from the database while the previous batch is still being restructured into
FDO. As I understand it though multi-threading is not built into C++ and
requires native platform code to create new threads.
--
View this message in context: http://www.nabble.com/SDF-3.0-FDO-Provider-Serious-Memory-Leak-tp18447913p18461604.html
Sent from the FDO Internals mailing list archive at Nabble.com.

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals