Glusterfs uses an asynchronous programming model where each component (xlator) calls into the next using STACK_WIND, passing a callback. The next xlator performs its task and then callbacks the original using STACK_UNWIND. This non-blocking approach prevents any xlator from blocking on network operations. Key data structures like the call_frame track the asynchronous call and callback between xlators, maintaining a stack. Debugging information within frames helps track errors like frame loss or stuck operations.

1. Glusterfs Session #4
Call_frame and programming model

2. Scope
- What is the programming model used in gluster
- Why this model is used
- What are the data structures that help with implementing it

3. What is the programming model used in gluster
- Glusterfs xlators use asynchronous programming model.
- Each xlator calls into the other xlator using a macro called STACK_WIND
giving it a callback function
- The other xlator once it finishes its part callback using the callback function
passed using STACK_UNWIND macro

4. Why this model is used
- Any xlator can’t assume what the other xlator is going to do with the fop
- If the xlator(Like client xlator) does a network operation, blocking the calling
xlator until response comes from server will kill performance. So non-blocking
sockets are used for communication.
- This forces every xlator to follow asynchronous programming model using
call/callback model.

6. Code walkthrough
- Stack wind and variants
- Stack unwind and variants
- C stack and gluster stack

7. Difference between C stack and gluster stack
struct _call_frame {
call_stack_t *root; /* stack root */
call_frame_t *parent; /* previous BP */
struct list_head frames;
gf_lock_t lock;
void *cookie; /* unique cookie */
xlator_t *this; /* implicit object */
ret_fn_t ret; /* op_return address */
...
};

8. Call_frame_t continued
struct _call_frame {
...
void *local; /* local variables */
glusterfs_fop_t op;
int32_t complete;
const char *wind_from;
const char *wind_to;
const char *unwind_from;
const char *unwind_to;
};

9. Stack-wind/unwind with cluster xlators
- Demo that shows the importance of call-count
- local is not accessed once all stack-winds are complete
- Demo

10. Debug information in frames
- What information is stored for debugging purposes
- How to debug frame-loss/stuck frames using statedumps
- Demo completed=0
- Demo how to look at frames and interpret

11. Q & A