Changes between Version 16 and Version 17 of rfc24_progressive_data_support

Timestamp:

Aug 27, 2008, 1:00:02 PM (16 years ago)

Author:

normanb

Comment:

--

rfc24_progressive_data_support

@@ -25 +25 @@
 [http://article.gmane.org/gmane.comp.gis.gdal.devel/16630/match=progressive+rendering Tamas Szekeres]
 
-1. It seems we are tending to spawn new threads in every RasterIO operations at driver level, which is quite inconvenient at the moment, therefore it should be considered with care. Will you allow RasterIO to be re-entered from the GDALProgFunc event handler or by another thread? Will you provide a copy of pBuff in GDALProgFunc or the same pointer will be passed back to the caller? How this buffer will be protected from the simultaneous access of the multiple threads?
+Question: It seems we are tending to spawn new threads in every RasterIO operations at driver level, which is quite inconvenient at the moment, therefore it should be considered with care. Will you allow RasterIO to be re-entered from the GDALProgFunc event handler or by another thread? Will you provide a copy of pBuff in GDALProgFunc or the same pointer will be passed back to the caller? How this buffer will be protected from the simultaneous access of the multiple threads?
+
+Response: 
+
+There will one thread at the RasterIO driver level communicating to the server and this will be separate to application thread, the driver will accept new window requests from the application and change the requests being made to the server within the thread.  There is a degree of synchronization required here, but this is hidden within the format driver.
+
+The callback function and the raster display will be in the main application thread, it will not be possible to update the format driver window from the callback function, but will be possible using RasterIO read as normal.
+
+pBuff will be small, it only contains the data for the currently request window at a particular resolution level and these are normally proportional, so small window implies higher resolutions, large window implies low resolution.  As such an initial version will provide a copy of the buffer rather than a pointer this should protect the buffer from corruption by multiple threads.
+
+
+
+
+