in threaded mode, tilecache could deadlock if the downstream pixel
source raised an error
senario:
- thread1 starts working on tile A and flags it as a CALC
(calculation in progress)
- thread2 needs tile A, sees it is being worked on, and blocks
until computation is done
- thread1 hits an error ... it correctly remarks the tile as
PEND (calculation pending), but does not broadcast a wake-up
signal
- thread2 stays blocked!
threads now broadcast a wakeup on tile error as well as on tile success
Thanks to Todd Patrick
we were calling quite a few funcs from inside the global lock, some of
which used the global lock themselves
have our own file operation lock, it's neater
with --centre turned on, in google maps mode dzsave will centre tiles
rather than placing them at the top-left
also, make sure blank.png is set to @background
in some cases dzsave could fail to write all the pyramid layers out
the problem was if a layer was odd-sized and needed rounding up so it
could be shrunk from, and if the tile size was such that the final strip
was sized exactly to fit the last line of pixels that would come into
this layer, the final line of pixels could never be interpolated
thanks to Martin for the report
The vips driver program was parsing options in a single pass. This
failed if an option came in two parts, for example:
vips --plugin x.plg list
the argument to --plug would be picked up as the action for "vips",
since actions were selected before option parsing
Now we parse in two passes: the first pass picks up options for vips
itself and for the libvips library, then we select the action, then we
parse again, including any options created by the action
google maps output needs threaded create / destroy of VipsArea (used to
hold the background colour). We need a lock on VipsArea::count.
Fixes https://github.com/jcupitt/libvips/issues/46
Thanks fuho
