On Wed, May 1, 2013 at 6:58 PM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:
I would say that the callback passed to STACK_WIND is very much like a
continuation, and a synctask is a thread even if there's one callback at
the end.
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?
As is usually the case with events vs. threads, the STACK_WIND
approach provides more flexibility but also breaks up the flow of
control and requires explicit (non-stack) state, so code is
significantly harder to read and debug.
Yes. This is what I meant when I said synctasks seem natural.
Unfortunately, synctasks also
hamper debugging in their own way because they use stacks that gdb can't
understand, so in many cases real threads are even better. My general
preference would be to use STACK_WIND etc. for main-line code and
threads for background/maintenance tasks with more complex
blocking/looping needs. In particular, any recursive code (such as
walking a directory tree in self-heal or rebalance) needs to be in a
thread or synctask because of stack-depth concerns.
Yes. Stack depth is one major difference b/w the two approaches.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
https://lists.nongnu.org/mailman/listinfo/gluster-devel
regards,
--
Raghavendra G
Raghavendra G
