Parallelizing calls to msDrawLayer()
szekerest at GMAIL.COM
Sat Oct 13 19:23:36 EDT 2007
2007/10/14, David Fuhry <dfuhry at cs.kent.edu>:
> I might be misunderstanding your point here, but... Rendering a layer
> into an independent imageObj should be a pretty independent operation,
> and could be made so if it's not now.
If the vtable functions implemented by the driver are not reentrant
then the rendering of the layers connected to the same driver is
definitely dependent. The drawing itself might be created
independently if mapserver and gd or agg could avoid using global
variables during the drawings.
The same applies to the drivers as well, however it's quite more
difficult to audit the code from this aspect because it might as well
depent on the subsequent libraries. Moreover we should consider not
only the globals (globally accessed static variables) but also all of
the potential common resources like database connections file handles
> Glancing at the mapserver
> thread-safety FAQ, it seems there are more unsafe & locked components
> related to data-fetching drivers than there are for rendering. Which
> makes me wonder why you suggest parallelizing the data-fetching but not
> the rendering.
Because I expect significantly greater increment in the performance by
parallelizing the data retrieval than the drawing (+ the extra image
> Forgive me if I'm playing a bit of devil's advocate here. I'm aware
> that non-reentrant functions don't rewrite themselves, and that critical
> sections don't surround themselves with mutexes.
Using a mutex in that function would serialize the the operation and
kill the parallel behaviour definitely. However currently the driver
operations are quite separated in fairly atomic operations so it
wouldn't involve too much problems.
> Surely though, it
> ought not to be a tremendous amount amount of work to keep separate
> layer-drawing operations from stepping on eachothers' toes?
I'm pretty sure currenly parallelizing the data retrieval is more
trivial that reconstructing the drawing logic inside mapserver.
For example the LayerWhichShapes data provider functions would trigger
an asynchronous fetch operation to the data source and later the
NextShape would serve the retrieved data from the memory when drawing
More information about the mapserver-dev