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

[Raghavendra G]

On Wed, May 1, 2013 at 6:58 PM, Jeff Darcy <jdarcy at redhat.com> 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 at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>


regards,
-- 
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130501/744126aa/attachment-0001.html>