----- 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.
> 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?
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxxx
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
