<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif">Even,</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">I'm actually surprised that it is considered impractical to make some/most drivers thread safe (read-only) natively and I thought key ones already were mostly there in the past though I'm not so confident in my memory.   Looking through the GTiff code I find myself not able to work out where locking is done and how we are managing the directory loading/switching as block reads are done. </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">I would certainly like to work towards read-only thread safety for some drivers with:</div><div class="gmail_default" style="font-family:arial,sans-serif"> - a shared block cache for all threads reading from a dataset</div><div class="gmail_default" style="font-family:arial,sans-serif"> - no duplication of file handles per-thread</div><div class="gmail_default" style="font-family:arial,sans-serif"> - a way of checking that a dataset is considered to be thread safe. </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">I'm curious if you can talk a bit more about the challenges of accomplishing the above.   I had been hoping to take advantage of my (assumption) that this already mostly existed in GDAL for our new high performance environment at Planet so it is of more than academic interest to me.  Also, doesn't gdalwarp's multithreading support already depend on read-only thread safety for source files?</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">The above said, I can also see some utility in RFC 101 and have no objection to it.  </div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,sans-serif">Best regards,</div><div class="gmail_default" style="font-family:arial,sans-serif">Frank</div><div class="gmail_default" style="font-family:arial,sans-serif"><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 6, 2024 at 12:45 PM Kurt Schwehr via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">My take would be to not offer the force option unless there is someone who states they really need it.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 6, 2024 at 6:52 AM Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
No other reactions? In particular w.r.t. the open question whether it is <br>
worth to offer a "force" mode in the situations where a dataset cannot <br>
be re-opened (or for a band whose belonging to a dataset cannot be <br>
determined) where the thread-safe wrapper would just put a mutex around <br>
the calls to that dataset/band (so obviously this wouldn't scale with <br>
the number of threads). I'm probably leaning on not offering this option <br>
for now, if there's no obvious need it is useful. It can always been <br>
added afterwards.<br>
<br>
Even<br>
<br>
Le 29/08/2024 à 14:26, Even Rouault via gdal-dev a écrit :<br>
> Hi,<br>
><br>
> I've worked on a new RFC 101: Raster dataset read-only thread-safety: <br>
> <a href="https://github.com/OSGeo/gdal/pull/10676" rel="noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/10676</a><br>
><br>
> Summary: This RFC enables users to get instances of GDALDataset (and <br>
> their related objects such as GDALRasterBand) that are thread-safe for <br>
> read-only raster operations, that is such instances can be safely used <br>
> from multiple threads without locking.<br>
><br>
> It is backed by a preliminary implementation (fairly complete, apart <br>
> from writing new tests...). There's at least one open question raised <br>
> in the RFC.<br>
><br>
> PS: you can see one of the benefits of the migration of the doc to <br>
> ReadTheDocs hosting, with the preview of the updated documentation in <br>
> pull requests. So this is a way to mention that the move to RtD <br>
> hosting has now been completed, with the default version ("latest") <br>
> reflecting the state of the master branch, as well as the version for <br>
> the release/3.9 branch. Thanks to Dan Baston (and other people <br>
> involved) for this work! There might be a few adjustments needed, so <br>
> if you notice something unusual w.r.t. to the previous state, please <br>
> file a ticket.<br>
><br>
> Even<br>
><br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><font face="monospace">---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>light and sound - activate the windows | USA: +1 650-701-7823<a href="http://voice.google.com/calls?a=nc,%2B16507017823" class="gv-tel-link" target="_blank" rel="noopener" title="Call +1 650-701-7823 via Google Voice"></a><a href="http://voice.google.com/calls?a=nc,%2B16507017823" rel="noopener" title="Call +1 650-701-7823 via Google Voice" target="_blank"></a><br>and watch the world go round - Rush    | CAN: +1 343-550-9984</font></div></div></div></div></div></div>