<div dir="ltr">What do you mean by "filter-by-filter" basis? Each filter is in its own thread?<div><br></div><div>If you need asynchronous IO, then a typical approach is to start the thread that does the IO, and then poll that thread until the IO is complete.  When the IO is complete, feed the data into your pipeline.  This solution is not specific to VTK in any way, of course.  It's just a general approach to asynchronous IO that works as well with VTK as with anything else.  You can also have the thread read the data piece-by-piece, which would be a bit more complicated.</div><div><br></div><div>It also works for asynchronous processing.  For long processing tasks, we start a QThread that does the processing and emits a signal when the processing is done.  When our app receives the signal, it knows it's safe to use the result.  In this case Qt is doing the polling for us as part of its mainloop.</div><div><br></div><div> - David</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 3:39 PM, eewing <span dir="ltr"><<a href="mailto:eewing@cs.uoregon.edu" target="_blank">eewing@cs.uoregon.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David,<br>
<br>
Thanks for the quick response. That actually answers my issue. I'm working on threaded I/O as part of a large pipeline, described by your first example. The pipeline is executed in parts by threads, but on a filter-by-filter basis, with no way to lock data to a specific thread.<br>
<br>
What would your recommendation be to mitigate the issue? I've seen a suggestion to create a "I'm accessing VTK" mutex for whenever you are accessing VTK, but I'd like to avoid that if possible.<br>
<br>
-Elliott<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 2016-01-13 14:20, David Gobbi wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Elliott,<br>
<br>
Can you describe your issue in more detail?  The VTK New and Delete<br>
calls should be thread safe. The two caveats for VTK and threads are:<br>
<br>
1) All classes that do rendering should be in the same thread (all<br>
mappers, actors, renderers, etc), and there shouldn't be multiple<br>
threads hitting the same rendering context.<br>
<br>
2) Movement of data between threads must be locked or otherwise done<br>
in a thread-safe manner.<br>
<br>
You would not, for example, create a single pipeline that is accessed<br>
from multiple threads.  Each thread would have its own pipeline<br>
segment, with locks to synchronize a copy (or move) of data from the<br>
output of one segment to the input of another segment.<br>
<br>
 - David<br>
<br>
On Wed, Jan 13, 2016 at 2:27 PM, eewing <<a href="mailto:eewing@cs.uoregon.edu" target="_blank">eewing@cs.uoregon.edu</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I'm running into some issues with VTK in a threaded environment,<br>
and it seems that the source of the problem is in VTK's New and<br>
Delete calls. So, are the New and Delete calls thread-safe? If not,<br>
is there a recommended alternative that I can use inside my threads?<br>
<br>
Best,<br>
-Elliott Ewing<br>
University of Oregon<br>
</blockquote></blockquote>
<br>
</div></div></blockquote></div><br></div></div></div>