2009/8/2 Mateusz Loskot <[email protected]>: > Jorge Arévalo wrote: >> Hello, >> >> 2009/8/2 Mateusz Loskot <[email protected]>: >>> Jorge Arévalo wrote: >>>> When I create an overview (a children dataset), its properties are >>>> the same properties of the general dataset (his parent), apart from >>>> pixel size, table name and column_name, of course. The problem >>>> appears when sharing the PGconn object. >>>> >>>> My code looks like this: >>>> >>>> poDS->overview[i]->hPGconn = poDS->hPGconn >>>> >>>> If each dataset's destructor (from the general one and from the >>>> overviews) calls PQfinish over the same object, I get a segmentation >>>> fault after the first time, of course. So, I have 2 options: - Detect >>>> when a connection object has been freed, and perform only one call. >>>> How should I do this? >>> If I understand it correctly, the problem can be summarised in some >>> kind of pseudo-code as follows: >>> >>> struct Overview >>> { >>> PGconn* c; >>> Overview(PGconn* c) : c(c) {} >>> ~Overview() { PQfinish(c); } >>> >>> }; >>> >>> struct Dataset >>> { >>> PGconn* c; >>> Dataset(char const* connstr) { /*connect to pgsql*/ } >>> ~Dataset() { PQfinish(c) ; c = 0; } >>> Overview get_overview() { return Overview(c); } >>> }; >>> >>> >>> { >>> Overview ov; >>> { >>> Dataset d(...); // connect >>> ov = d.get_overview(); // side-effect: share connection >>> } // Dataset dctor calls PQfinish >>> >>> // Problem #1: Overview's connection no longer valid >>> } // Problem #2: Overview dctor tries to close and fails >>> >>> Note: Overview here may be a subdataset, no difference between the two >>> for the problem analysis. >> >> Yes, the problem looks like that. >> >>> Assuming this example reproduces the problem correctly, then >>> there is no way to detect in Overview's dctor that >>> connection is still valid. >> >> Ok, but maybe the Even's idea of a boolean var set to TRUE in dataset >> and to FALSE in overviews could be a good way to simulate this >> situation. > > Sure, it is but as long as you're confident that you > can determine who's the base - master dataset/overview/subdataset. > > Clearly I lack of details and I've not read your code. > Thus, I may have been able to see the issue only partially, > so can't see & suggest best option.
Anyway, things are more clear now, many thanks. Your analysis is valid for my situation. Best regards, Jorge > > Best regards, > -- > Mateusz Loskot, http://mateusz.loskot.net > Charter Member of OSGeo, http://osgeo.org > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
