<div dir="ltr">That sounds reasonable to me.<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 4:12 PM, paul mccarthy <span dir="ltr"><<a href="mailto:pauldmccarthy@gmail.com" target="_blank">pauldmccarthy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Nathaniel,<div><br></div><div>True - perhaps such a method could be added to the <font face="monospace, monospace">Opener</font> class (with the internal seek/read calls protected by a mutex), and used by <font face="monospace, monospace">read_segments</font><font face="arial, helvetica, sans-serif">, instead of separate </font><font face="monospace, monospace">seek</font><font face="arial, helvetica, sans-serif">/</font><font face="monospace, monospace">read</font> calls. This would be a very simple change - I'm happy to prepare a PR if it sounds like a good idea.</div><div><br></div><div>Cheers,</div><div><br></div><div>Paul</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 8 February 2017 at 20:23, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">The best solution would be to use a pread-style interface that lets you read from a given offset without seeking at all, and thus without needing any locks. Unfortunately, Python hasn't historically had the best support for this, but it's available if you're using Python 3 on unix: <a href="https://docs.python.org/3/library/os.html#os.pread" target="_blank">https://docs.python.org/<wbr>3/library/os.html#os.pread</a><span class="m_-7761283364306288238HOEnZb"><font color="#888888"><div dir="auto"><div dir="auto"><div dir="auto"><br></div><div dir="auto">-n</div></div></div></font></span></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-7761283364306288238h5">On Feb 8, 2017 5:55 AM, "paul mccarthy" <<a href="mailto:pauldmccarthy@gmail.com" target="_blank">pauldmccarthy@gmail.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-7761283364306288238h5"><div dir="ltr">Howdy all,<div><br></div><div>Does anybody have experience accessing image data through the <font face="monospace, monospace">ArrayProxy</font> class (or functions in the <font face="monospace, monospace">fileslice</font> module) in a multi-threaded environment? I am visualising large 4D images which are kept on disk (via my <font face="monospace, monospace">indexed_gzip</font> module), and am having trouble when accessing the data from multiple threads, as the <font face="monospace, monospace">seek</font>/<font face="monospace, monospace">read</font> pairs from different threads will occasionally become intertwined with each other.</div><div><br></div><div><br></div><div>My hacky workaround is to patch the <font face="monospace, monospace">ArrayProxy.__getitem__</font> method, and add a <font face="monospace, monospace">threading.Lock</font> to each instance, as follows:</div><div><br></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">import threading</font></div><div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">import nibabel            as nib<br></font></div><div><font face="monospace, monospace">import nibabel.arrayproxy as ap</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">def ArrayProxy__getitem__(self, slc):</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    if not hasattr(self, '_thread_lock'):</font></div><div><font face="monospace, monospace">        return self.__real_getitem__(slc)</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    self._thread_lock.acquire()</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">    try:</font></div><div><font face="monospace, monospace">        return ap.ArrayProxy.__real_getitem__<wbr>(self, slc)</font></div><div><font face="monospace, monospace">    </font></div><div><font face="monospace, monospace">    finally:</font></div><div><font face="monospace, monospace">        self._thread_lock.release()</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"># Patch ArrayProxy.__getitem__</font></div><div><font face="monospace, monospace">ap.ArrayProxy.__real_getitem__ = ap.ArrayProxy.__getitem__</font></div><div><font face="monospace, monospace">ap.ArrayProxy.__getitem__      = ArrayProxy__getitem__</font></div></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"># Then add a lock to instances </font></div><div><font face="monospace, monospace"># which need to be thread-safe</font></div><div><font face="monospace, monospace">img = nib.load('MNI152_T1_2mm.nii.gz<wbr>')</font></div><div><font face="monospace, monospace">img.dataobj._thread_lock = threading.Lock()</font></div><div><br></div><div><br></div><div>This is the first thing I came up with, although I will probably end up adding the lock to the <font face="monospace, monospace">fileobj</font>, and patching the<font face="monospace, monospace"> fileslice.fileslice</font> function instead. Unless there are any better ideas?</div><div><br></div><div>Cheers,</div><div><br></div><div>Paul</div></div>
<br></div></div><span>______________________________<wbr>_________________<br>
Neuroimaging mailing list<br>
<a href="mailto:Neuroimaging@python.org" target="_blank">Neuroimaging@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/neuroimaging" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/neuroimaging</a><br>
<br></span></blockquote></div></div>
<br>______________________________<wbr>_________________<br>
Neuroimaging mailing list<br>
<a href="mailto:Neuroimaging@python.org" target="_blank">Neuroimaging@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/neuroimaging" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/neuroimaging</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Neuroimaging mailing list<br>
<a href="mailto:Neuroimaging@python.org">Neuroimaging@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/neuroimaging" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/neuroimaging</a><br>
<br></blockquote></div><br></div></div>