[gdal-dev] GDAL Progressive Data Support RFC Discussion

[Tamas Szekeres]

Frank,

The described approach with regards to the API seems reasonable for me, I
recall I took part in the conversation that time when the initial version
have been worked out, and I remember of most aspect.

Just by having a quick review of the code I have the following
questions/concerns:


1. The implementation of the PERSISTENT flag is handled by using a static
curl handle shared by multiple threads without having synchronization in the
cpl code. I'm not sure whether it's completely guarded by the driver level
mutex (pGlobalMutex), however it would be better to do the sync in-place
where the shared variable is declared. This would require for example to
place http_persistent_handle either at the driver, or do the sync in the CPL
code.

2. Not sure whether it's safe to use the same curl handle by multiple
threads (either with syncing or without).

3. Could you explain the reason of using 2 worker threads (with different
priorities) at the driver? I'm not sure about the use case where these 2
threads are required to have.

4. It would be reasonable to use (probably by extenting the CPL code)
sychronized waiting instead of
busy-waiting<http://en.wikipedia.org/wiki/Busy_waiting>implemented in
the diver code. This cause for example the implementation of
JPIPKAKAsyncRasterIO::Stop() getting odd, and error prone. For instance it
may result in a wait forever condition if the thread would terminate without
setting the exit flag correctly. By using a synchronized wait approach
instead (ie an event handle) the wait function would terminate with an error
if the owner thread have been terminated in the meantime.

5. The diver doesn't seem to do any specific if CPLAcquireMutex fails or
returns with timeout (by not getting the ownership of the mutex in effect)


By all means I have no problem with the API (which appears to be the primary
subject of this RFC)

Best regards,

Tamas



2010/3/12 Frank Warmerdam <warmerdam at pobox.com>

> Folks,
>
> I have spent several days working on the JPIP driver initiated by
> Norman Barker, and also worked on by Garrett Briggs.  This driver
> uses a proposed new method for asynchronous and progressive data
> access for GDAL.  The driver now seems to be working fairly well, and
> based on that work I have fleshed out the RFC for the proposed new
> API.
>
> The implementation can be found in:
>
>  http://svn.osgeo.org/gdal/sandbox/normanb/gdal
>
> It is somewhat hard to build due to the Kakadu dependency - some makefile
> hacking may be required.
>
> The RFC can be found at:
>
>  http://trac.osgeo.org/gdal/wiki/rfc24_progressive_data_support
>
> Currently I am calling for discussion on the proposed interface - similar
> to what it was on the last round, though I've tried to clarify a few issues
> and streamlined away a few items.
>
> Depending on feedback I hope to call for a vote on the RFC within a couple
> of days.
>
> Best regards,
> --
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam<http://pobox.com/%7Ewarmerdam>
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100313/dfa31c7a/attachment.html