[Gluster-devel] rpc problems when using syncops in callbacks

[Jeff Darcy]

On 05/01/2013 03:41 AM, Raghavendra G wrote:
> This comment made me think what are the advantages of syncop framework
> over STACK_WIND/UNWIND framework (even when you are using synctask_new
> in non-blocking mode by providing a cbk). After discussion with Avati,
> it became clear that the actual benefit is not really whether
> synctask_new is blocking or non-blocking. It is actually that you can do
> synchronous operations in your synctask (or to put it crudely in your
> function that you pass as an argument to synctask). Some of these
> operations are already implemented in the form of synchronous fops (like
> syncop_lookup etc). But the core benefit of syncop framework is that you
> can "yield" (from executing your task's code to execute a different
> task's code) and "wake" the thread at any point in your code. This more
> fine grained "control" (which is basically continuations) is lacking in
> STACK_WIND/UNWIND framework.

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.  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.  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.