I wanted to call to everyone's attention the work I have been doing in an
attempt to make it possible for more portions of GDAL to be thread safe and
improve speed in multi-threaded environments. I have put a RFC up here:
http://trac.osgeo.org/gdal/wiki/rfc47_dataset_caching
Originally my work
Even,
Thank you very much for response to this, your helping me understand all of
this stuff has been very valuable.
I'm not sure the ratio gain/effort to make dataset methods a bit more
thread
safe is high enough. Very few drivers can be made fully thread-safe, and
fully
parallelized (i.e.
Even,
I am not yet a commiter on SVN, but I agree with Tamas that allowing any
commiters would be a great. I personally think listing supporting companies
with an opensource project is a great way to build more support and trust
in the project.
Thanks,
Blake
On Wed, Aug 20, 2014 at 3:51 PM,
design outside of just a non global cache
for datasets.
Blake Thompson
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Robert,
I agree - from reading it seems like the major improvement is shifting
away from a global, locking cache to a per-dataset cache. (ah. has been
edited since you read it?)
Yes, I updated the RFC some yesterday after the email from Jeff Lacoste. He
forgot to hit reply all so it ended
Jeff,
Thanks Blake for the detailed response. I did not realize that I did not do
a reply all in my previous email I sent.
Not an issue, glad you guys are interested in my changes.
-- I thought that this was not possible using current trunk GDAL because
of the global cache. At least the
Kurt,
On Fri, Aug 22, 2014 at 9:07 AM, Kurt Schwehr schw...@gmail.com wrote:
I've got threading issues on my list of things to investigate with GDAL.
I've been running MSAN on GDAL lately and want to get TSAN going too. I'm
out on leave this month, but hope to get more into this stuff
Kurt,
With a 2 week old baby, my brain has been soggy.
Congrats!
I do see the 3 threads here:
http://lists.osgeo.org/pipermail/gdal-dev/2014-August/thread.html
The asan/msan/tsan tools are
asan - address sanitizer - https://code.google.com/p/address-sanitizer/
msan - memory
Even,
This might be a problem in practice since the amount of cache might grow
quickly. By default a VRT will open simultaneously up to
GDAL_MAX_DATASET_POOL_SIZE (whose default is 100, but can be changed at
runtime with the config option) source datasets.
If you do a gdal_translate of the
Even,
On Fri, Aug 22, 2014 at 1:33 PM, Even Rouault even.roua...@spatialys.com
wrote:
Note: after re-reading, I realize that I misread your above sentence as it
will work to translate multiple datasets in a parallel way with a *per-
dataset* cache).
So, even if you didn't write it, I'm
Even,
The naming is perhaps not well choosen, but the documentation of the
contract
of this API should make it clear on what an implementation should do and
what
it should not do.
Perhaps it should be reversed? IReadBlock and IReadBlock_not_thread_safe?
(would obviously require lots of
Even,
Yeah, that why was I suggested the reverse ;-) But an automatic renaming
should be doable.
Another danger of keeping IReadBlock and making it now responsible of
ensuring
its thread safety is for out-of-tree drivers that wouldn't realize they
need
to change something as code would
Even and Andre,
I want to start off by saying a big thanks to Blake for taking his time
to tackle what can only be a very difficult problem.
From what I can observe, the current discussion seems to be around the
boundary of who should be responsible for ensuring thread safety around
the
[gdal-dev-boun...@lists.osgeo.org]
w
imieniu Blake Thompson [flippm...@gmail.com]
Wys³ano: 29 sierpnia 2014 02:35
Do: Even Rouault
DW: gdal-dev@lists.osgeo.org
Temat: Re: [gdal-dev] RFC 47 and Threading
Even and Andre,
I want to start off by saying a big thanks to Blake for taking
to do this properly.
If you have any questions specifically about Mapnik Vector Tile or the
Mapbox Vector Tile Specification feel free to ask me. I would note that you
guys will want to update your vector tiles once the V2 specification
changes are into Mapnik-Vector-Tile.
Thanks,
Blake Thompson
Even,
He is correct that MBTiles can store vector tiles. I know this is done in
https://github.com/mapbox/tippecanoe . I believe there is talk about
updating the MBTiles Spec as well.
Thanks,
Blake Thompson
On Tue, Jan 5, 2016 at 2:21 PM, Even Rouault <even.roua...@spatialys.com>
wrote:
This was especially true when I
was writing 2.0 of the specification as I tried to limit what would be
considered even the most common uses of vector tiles.
Thanks,
Blake Thompson
On Mon, Feb 1, 2016 at 4:27 PM, Stefan Keller <sfkel...@gmail.com> wrote:
> Hi Ben
>
>
and check
them in on occasion (such as after big changes or before releases)
- Optimize the style for reading now for writing of the code
- If you want to be really strict you can have style checked as part of
testing (I am not personally a huge fan of this).
Thanks,
Blake Thompson
On Fri, May 5,
this problem I am more then willing to lend my expertise.
Thanks,
Blake Thompson
On Wed, Feb 14, 2018 at 10:53 AM, Rahkonen Jukka (MML) <
jukka.rahko...@maanmittauslaitos.fi> wrote:
> Even Rouault wrote:
>
> > Perhaps you could play with the SIMPLIFICATION and
> SIMPLIFICA
19 matches
Mail list logo
