In addition to the zarr sink being compatible with multithreading, this PR makes the zarr sink compatible with multiprocessing. This is accomplished by the following:
splitting the addLock into threadLock and processLock (each a different class)
changing how a zarr sink is initialized from a path; now made more predictable by using os.tempdir as the root rather than a generated tempdir.TemporaryDirectory() and opened with "append" mode via zarr
removing the clause to set self.unpickleable = True
adding a pytest to check the behavior of both multithreading and multiprocessing cases
With this addition, there continues to be the caveat that the size of the whole image must be known before any multiprocessing or multithreading can work. The image size cannot be changed within a thread or process. The test reflects this; the last tile in the tileset (at the maximum extents) is added first, then all other tiles are added within a thread or process.
In addition to the zarr sink being compatible with multithreading, this PR makes the zarr sink compatible with multiprocessing. This is accomplished by the following:
addLockintothreadLockandprocessLock(each a different class)os.tempdiras the root rather than a generatedtempdir.TemporaryDirectory()and opened with "append" mode via zarrself.unpickleable = TrueWith this addition, there continues to be the caveat that the size of the whole image must be known before any multiprocessing or multithreading can work. The image size cannot be changed within a thread or process. The test reflects this; the last tile in the tileset (at the maximum extents) is added first, then all other tiles are added within a thread or process.