Even Rouault wrote:
I don't know JPIP, but I can image that the driver would start a thread when
AsyncRasterIO() is called. It communicates with the server and receives the
updates with a polling loop. When it has received an update,it put the
received data as well as the parameters describing the window, etc... in a
structure (let's call it a ticket), pushes that ticket in a stack and goes on
pushing tickets, or wait for the ticket to be consumed by the reader (both
are possible, even if you can't push continuously new tickets as memory will
increase, so the working thread would have to go in idle mode until the queue
decreases a bit)
The NextAsyncRasterIOMessage() call will check that some message is available
and unstack the first ticket. In fact, the LockBuffer() / UnlockBuffer()
could probably be avoided at the API level. Of course the implementation of
NextAsyncRasterIOMessage() needs an internal mutex to protect the accesses to
the queue.
My idea was to update the data buffer given to AsyncRasterIO immediately
after receiving data and write only window coordinates into the queued
messages. That way the queue will remain small, a few KB's at most. This
is also why LockBuffer() / UnlockBuffer() is there, to protect the
buffer from async updates while we read from it. LockBuffer(xoff, yoff,
xsize, ysize) allows almost no wait operation if used with coords from
queue.
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
