<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 1, 2013 at 6:58 PM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
</div>I would say that the callback passed to STACK_WIND is very much like a<br>
continuation, and a synctask is a thread even if there's one callback at<br>
the end. </blockquote><div><br></div><div>Yes, both are essentially continuations (probably I was being wrong when I said synctasks provide more fine grained control - one could do a STACK_WIND at the place of yield). But, synctask seems more natural implementation. We don't have to differentiate b/w the work being done (an fop like write) and the C function (like wb_writev) (wb_writev can return with fop writev not being complete). Whenever I start thinking about the difference, I keep running into the question whether we had considered the syncop way (using swapcontext family of functions - for eg., we could have yielded after writing to network and woke up when reply comes back. But this method requires at least one extra idle synctask - which start their life reading /dev/fuse) when we thought of STACK_WIND/UNWIND macros? Avati, any comments on this?<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> As is usually the case with events vs. threads, the STACK_WIND<br>
approach provides more flexibility but also breaks up the flow of<br>
control and requires explicit (non-stack) state, so code is<br>
significantly harder to read and debug. </blockquote><div><br></div><div>Yes. This is what I meant when I said synctasks seem natural.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Unfortunately, synctasks also<br>
hamper debugging in their own way because they use stacks that gdb can't<br>
understand, so in many cases real threads are even better. My general<br>
preference would be to use STACK_WIND etc. for main-line code and<br>
threads for background/maintenance tasks with more complex<br>
blocking/looping needs. In particular, any recursive code (such as<br>
walking a directory tree in self-heal or rebalance) needs to be in a<br>
thread or synctask because of stack-depth concerns.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>Yes. Stack depth is one major difference b/w the two approaches.<br> <br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="HOEnZb"><div class="h5">
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"></div><div class="gmail_extra">regards,<br></div><div class="gmail_extra">-- <br>Raghavendra G<br>
</div></div>