[Gluster-devel] Shared resource pool for libgfapi

Krishnan Parthasarathi kparthas at redhat.com
Mon Jun 8 12:08:53 UTC 2015


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


More information about the Gluster-devel mailing list