[Gluster-devel] Issue with THIS and libgfapi

[Poornima Gurusiddaiah]

> 
> ----- Original Message -----
> > From: "Jeff Darcy" <jdarcy at redhat.com>
> > To: "Poornima Gurusiddaiah" <pgurusid at redhat.com>
> > Cc: "Gluster Devel" <gluster-devel at gluster.org>
> > Sent: Wednesday, May 13, 2015 12:39:29 PM
> > Subject: Re: [Gluster-devel] Issue with THIS and libgfapi
> > 
> > > Before the master xlator (fuse/libgfapi) is created, all the code that
> > > access
> > > THIS will be using global_xlator object,
> > > defined globally for the whole of the process.
> > > The problem is when multiple threads start modifying THIS, and overwrite
> > > thr
> > > global_xlators' ctx eg: glfs_new:
> > > glfs_new () {
> > > ...
> > > ctx = glusterfs_ctx_new();
> > > glusterfs_globals_inti();
> > > THIS = NULL; /* implies THIS = &global_xlator */
> > > THIS->ctx = ctx;
> > > ...
> > > }
> > > The issue is more severe than it appears, as the other threads like
> > > epoll,
> > > timer, sigwaiter, when not executing in
> > > fop context will always refer to the global_xlator and
> > > global_xlator->ctx.
> > > Because of the probable race condition
> > > explained above we may be referring to the stale ctxs and could lead to
> > > crashes.
> > 
> > Is it not true that we *want* multiple threads to share some of these data
> > structures?  For example, it seems like multiple epoll threads should be
> > operating on the same set of file descriptors and so on; they just need to
> > do so in a controlled way.
> 
> AFAIK, THIS was/is a convenient way of accessing xlator object in whose
> context we are executing (instead of passing down it as an argument in every
> function in the call stack). Going by this requirement, its unlikely that we
> want multiple threads share THIS. However, I am not very clear on the
> purpose of having THIS pointing to global xlator when we are not executing
> in any xlator context.

The purpose of global_xlator:
- To be used (mostly for mem accnt) before the master xlator(gfapi/Fuse) is created
- Gives the current ctx, it is executing as a part of
- To be used by the epoll and other threads to account memory for
  non fop functions like the mgmt functions etc.

> 
> > If that's the case, then it's not clear that
> > having per-thread global_xlator objects will really work.  Am I not
> > correctly understanding the nature of the problem?
> > 

Yes multiple threads need to share some of the data structures.
And global_xlator should be shared across threads, the problem explained above 
is when it is shared across multiple glusterfs_ctxs. In this case global_xlator
may point to the stale ctx instead of current ctx.

Regards,
Poornima