On Wed, May 1, 2013 at 6:58 PM, Jeff Darcy <[email protected]> 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/gluster-devel > regards, -- Raghavendra G
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
