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

Maksim Sestic max at geoinova.com
Tue Jul 15 12:18:57 EDT 2008


Badreddine, the problem here seems to be related to FDO managed wrappers and
certain constraints they pose, not providers' thereading capability per se.

Regards,
Maksim Sestic

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Badreddine
Karoui
Sent: Tuesday, July 15, 2008 15:39
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SDF 3.0 FDO Provider Serious Memory Leak

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-tp18447913p18
461604.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
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals

__________ NOD32 3269 (20080715) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com




More information about the fdo-internals mailing list