> 1) What is the difference between STACK_WIND
> and STACK_WIND_COOKIE? I.e. I've only
> ever used STACK_WIND, when should I use
> it versus the other?
>
> STACK_WIND_COOKIE is used when we need to 'tie' the call
> wound with its corresponding callback. You can see this
> variant being used extensively in cluster xlators where it
> is used to identify the callback with the subvolume no. it
> is coming from.
Ok - thanks. I will take a closer look at the examples for
this .. this may help me ...
> 2) Is there a way to write linearly within a single
> function within Gluster (or is there a reason
> why I wouldn't want to do that)?
>
>
> RE 2:
>
> This may stem from my lack of understanding
> of the broader Gluster internals. I am performing
> multiple fops per fop, which is creating structural
> inelegances in the code that make me think I'm
> heading down the wrong rabbit hole. I want to
> say;
>
> read() {
> // pull in other content
> while(want more) {
> _lookup()
> _open()
> _read()
> _close()
> }
> return iovec
> }
>
>
> But the way I've understood the Gluster internal
> structure is that I need to operate in a chain of
> related functions;
>
> _read_lookup_cbk_open_cbk_read_cbk() {
> wind _close()
> }
>
> _read_lookup_cbk_open_cbk() {
> wind _read()
> add to local->iovec
> }
>
> _lookup_cbk() {
> wind _open()
> }
>
> read() {
> while(want more) {
> wind _lookup()
> }
> return local->iovec
> }
>
>
>
> Am I missing something - or is there a nicer way of
> doing this?
>
> The above method you are trying to use is the "continuation passing style" that
> is extensively used in afr-inode-read.c and afr-transaction.c to perform multiple
> internal fops on the trigger of a single fop from the application. cluster/afr may
> give you some ideas on how you could structure it if you like that more.
These may have been where I got that code style from
originally .. I will go back to these two programs, thanks
for the reference. I'm currently working my way through
the afr-heal programs ..
> The other method I can think of (not sure if it would suit your needs)
> is to use the syncop framework (see libglusterfs/src/syncop.c).
> This allows one to make a 'synchronous' glusterfs fop. inside a xlator.
> The downside is that you can only make one call at a time. This may not
> be acceptable for cluster xlators (ie, xlator with more than one child xlator).
In the syncop framework, how much gets affected when I
use it in my xlator. Does it mean that there's only one call
at a time in the whole xlator (so the current write will stop
all other reads) or is the scope only the fop (so that within
this write, my child->fops are serial, but neighbouring reads
on my xlator will continue in other threads)? And does that
then restrict what can go above and below my xlator? I
mean that my xlator isn't a cluster xlator but I would like it
to be able to be used on top of (or underneath) a cluster
xlator, will that no longer be possible?
> Hope that helps,
> krish
Thanks Krish, every bit helps!
--
Ian Latter
Late night coder ..
http://midnightcode.org/
