[gdal-dev] GDALEndAsyncReader() takes long time to return

Frank Warmerdam warmerdam at pobox.com
Thu Feb 2 19:05:08 EST 2012

On Thu, Feb 2, 2012 at 3:49 PM, Robert Zermeno <refriguy68 at yahoo.com> wrote:

> I am trying to stream JPIPs.  I have two threads that are accessing the
> same file using the same GDALfiledataset.  One thread is a subsample image
> used as a navigator and the other thread is the full-sized image for the
> viewer to see the full image.
> Each thread uses its own GDALAsyncReaderH Object.  Each thread detects if
> the AsyncReader object is not NULL prior to calling
> GDALBeginAsyncReader().  If either AsyncReader is not NULL, then call
> GDALEndAsyncReader().  Sounds good right?
> Has anyone experienced the issue of GDALEndAsyncReader() taking longer
> than 10-20 seconds to return?  Can someone explain to me why it might take
> that long just to delete the AsyncReader object for JPIP to be able to
> process my next wanted region?
> I hope that makes since for anyone to answer my quest.  If not, let me
> know as I can provide more information.  I am currently using the
> repository build from 2-1-2012


The JPIP driver implementation is a bit messy and I suspect
much more complicated than it really needs to be.  Looking
at the JPIPKAKAsyncReader::Stop() method it seems there is
interaction with a global mutex (global to the dataset that is), and
then potentially waiting for the work thread to report back that it
is complete.  It is not immediately obvious to me why this would
take a long time.

It looks like the Stop() function effectively sets one
of bHighThreadRunning or bLowThreadRunning to FALSE
as an indicator that the JPIPWorkerFunc() should stop after
it has finished processing it's next chunk from the server.
Depending on chunk size and latency this might be a while
I suppose.  In theory we might be able to make the
JPIPWorkerFunc() do more fine grained checking - for
instance between reading of data by http and processing
it via the jpeg2000 ReadFromInput() method.

I'd suggest turning on debug output (eg. CPL_DEBUG=ON)
and add some debug output in JPIPWorkerFunc to see if it
is holding things up.  Possibly it is also some problem getting
one of the mutexes.  I didn't normally have more than one
async request at a time so there could be some fails in
the periods over which the mutexes are held.

Patches welcome!

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
and watch the world go round - Rush    | Geospatial Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120202/0a792d5b/attachment.html

More information about the gdal-dev mailing list