On Tue, 19 May 2015 13:06:45 +0200, Paolo Cavallini wrote:
Hi all.
Does this imply we have to change the qgis provider for SL?
certainly yes: any C/C++ sw component directly linking libspatialite
is expected to urgently switch from the deprecated spatialite_init()
to the new thread safe approach based on spatialite_alloc_connection(),
spatialite_init_ex() and spatialite_cleanup()
a perfectly equivalent approach could be the one based on dynamically
loading the "mod_spatialite" extension module on the top of libsqlite
thus definitely removing any direct linkage between the application
and spatialite itself.
this second approach is universal and is absolutely language agnostic
(and is fully thread safe as well).
the calling app simply has to execute the following SQL query on behalf
of any SQLite connection requiring SpatiaLite support:
SELECT load_extension( 'mod_spatialite' );
this is the way usually adopted by Java/JDBC, Python, PHP, C# .NET
(and many others), and there are many pros in this approach:
- the external dynamic module will silently take care of any required
initialization and finalization step.
- any external dependency from libspatialite headers and binaries
will completely disappear, because this one simply is a pure SQL
extension mechanism and is completely invisible at C/C++ level.
- the app and the module will be mutually independent; if you wish
to upgrade SpatiaLite to a more recent version you simply have
to replace mod_spatialite (and its related dependencies) and
that's all.
- there is an obvious con: if for any reason the dynamic extension
module will fail to load you'll probably experience an unexpected
fatal failure directly at run time.
and this explains why many C/C++ apps still continue to support
the standard approach based on direct linking.
the classic C/C++ initialization method based on direct linkage
now works as follows:
Connection:
----------------------
c1. get a valid SQLite handle by calling sqlite3_open_v2()
c2. allocate a spatialite's internal opaque object by calling
spatialite_alloc_connection()
the handle pointing to this opaque object must be preserved
during all the connection's lifetime.
c3. then you can initialize SpatiaLite on that connection by
calling spatialite_init_ex(sqlite_handle, opaque_internal_handle)
Termination:
---------------------
t1. you should first invoke sqlite3_close() as usual.
t2. and immediately after you should finalize the internal opaque
object by calling spatialite_cleanup()
[you are obviously expected to pass to this API exactly the
same pointer returned by the previous call to
spatialite_alloc_connection() for the corresponding connection]
all this nicely fits into a typical C++ class supporting Open()
and Close() methods; and in this case the internal opaque pointer
will simply be a private class member.
from a quick glance at the QGIS sources I notice that there are
many calls to sqlite3_open(), sqlite3_close() and spatialite_init()
dispersed here and there within the code of both e.g.
qgsspatialiteconnection.cpp and qgsspatialiteprovider.cpp
a preliminary reordering work mainly focused on centralizing
all Open() and Close() operations in a single C++ class will
presumably made the transition to the new spatialite_init_ex()
model absolutely painless.
bye Sandro
-------- Messaggio Inoltrato --------
Return-Path: <[email protected]>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from localhost (localhost [127.0.0.1]) by
paguma.faunalia.it
(Postfix) with ESMTP id F1B49108AC1B for <[email protected]>;
Tue,
19 May 2015 12:57:04 +0200 (CEST)
Received: from paguma.faunalia.it ([127.0.0.1]) by localhost
(paguma.faunalia.it [127.0.0.1]) (amavisd-new, port 10024) with LMTP
id
nHoMM_r_bo0O for <[email protected]>; Tue, 19 May 2015 12:57:02
+0200 (CEST)
Received: from lists.osgeo.org (mail.osgeo.osuosl.org
[140.211.15.134])
by paguma.faunalia.it (Postfix) with ESMTP id 6EB9A1082394 for
<[email protected]>; Tue, 19 May 2015 12:57:01 +0200 (CEST)
Received: from ash.osuosl.org (localhost [127.0.0.1]) by
lists.osgeo.org
(Postfix) with ESMTP id 1296D8661; Tue, 19 May 2015 03:56:50 -0700
(PDT)
Received: from mta.ntc.it (mta.ntc.it [212.83.162.48]) by
lists.osgeo.org (Postfix) with ESMTP id B4D658203 for
<[email protected]>; Tue, 19 May 2015 03:56:48 -0700 (PDT)
Received: from mail.lqt.it (mta.ntc.it [212.83.162.48])
(Authenticated
sender: [email protected]) by mta.ntc.it (Postfix) with ESMTPA id
902D110785B for <[email protected]>; Tue, 19 May 2015 12:56:44
+0200 (CEST)
MIME-Version: 1.0
Date: Tue, 19 May 2015 12:56:44 +0200
From: [email protected]
To: [email protected]
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
Message-ID: <[email protected]>
X-Sender: [email protected]
User-Agent: Roundcube Webmail/0.5.3
X-Netcom-MailScanner-Information: Please contact the ISP for more
information
X-Netcom-MailScanner-ID: 902D110785B.A7CE8
X-Netcom-MailScanner: Found to be clean
X-Netcom-MailScanner-From: [email protected]
Subject: Re: [gdal-dev] ogr2ogr segfault
X-BeenThere: [email protected]
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: "Discussion for developers using and building GDAL/OGR."
<gdal-dev.lists.osgeo.org>
List-Unsubscribe: <http://lists.osgeo.org/mailman/options/gdal-dev>,
<mailto:[email protected]?subject=unsubscribe>
List-Archive: <http://lists.osgeo.org/pipermail/gdal-dev>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://lists.osgeo.org/mailman/listinfo/gdal-dev>,
<mailto:[email protected]?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: [email protected]
Errors-To: [email protected]
On Tue, 19 May 2015 11:25:27 +0200, Even Rouault wrote:
Debian Sid, might be a platform specific issue?
https://bugs.debian.org/785091
few technical details useful to understand better:
a) starting since November 2013 it become definitely clear
that the older self-registration mechanism based on the
spatialite_init() API was intrinsically thread unsafe
and could potentially have very bad interactions with
the more recent versions of both PROJ.4 and GEOS
b) consequently a public announcement [1] was duly released
warning about the deprecation of spatialite_init()
and soliciting developers and maintainers to start
supporting the alternative thread safe mechanism based
on spatialite_alloc_connection(), spatialite_init_ex()
and spatialite_cleanup() APIs.
c) all recent versions of libspatialite, spatialite-tools
and spatialite_gui are now expected to be fully thread
safe: and AFAIK the same is for recent versions of GDAL.
any obsolete version still based on the nowadays deprecated
spatialite_init() API is potentially at risk when deployed
in a multithread configuration.
OTH Sandro
[1]
https://groups.google.com/forum/#!searchin/spatialite-users/spatialite_init_ex/spatialite-users/83SOajOJ2JU/sgi5fuYAVVkJ
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
