> Looking at it from a different perspective... > > As I understand it, the purpose of glusterfs_ctx is to be a container > for these resources. Therefore, the problem is not that the resources > aren't shared within a context but that the contexts aren't shared > among glfs objects. This happens because we unconditionally call > glusterfs_ctx_new from within glfs_new. To be honest, this looks a > bit like rushed code to me - a TODO in early development that never > got DONE later. Perhaps the right thing to do is to let glfs_new > share an existing glusterfs_ctx instead of always creating a new one. > It would even be possible to make this the default behavior (so that > existing apps can benefit without change) but it might be better for > it to be a new call. As a potential future enhancement, we could > provide granular control over which resources are shared and which > are private, much like clone(2) does with threads. Yes, this makes sense. I see that there are a few members of glusterfs_ctx_t(ctx) that needs to be handled with care. ctx assumes that there is only one volume being managed in a glusterfs* process. It has only one volfile-server connection, only one client_t table for connections to a volume etc. These are some things one needs to take care while making ctx, the container object for shared resources. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
