>
> ----- Original Message -----
> > From: "Jeff Darcy" <jdarcy@xxxxxxxxxx>
> > To: "Poornima Gurusiddaiah" <pgurusid@xxxxxxxxxx>
> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
> > Sent: Wednesday, May 13, 2015 12:39:29 PM
> > Subject: Re: 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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
