[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