> 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. 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
