[Gluster-devel] Shared resource pool for libgfapi

[Krishnan Parthasarathi]

> 
> Initially ctx had a one to one mapping with process and volume/mount, but
> with libgfapi
> and libgfchangelog, ctx has lost the one to one association with process.
> The question is do we want to retain one to one mapping between ctx and
> process or
> ctx and volume.

Yes and no. The problem is with viewing 'ctx' as panacea. We need to break it
into objects which have their own independent per-volume, per-process
relationships.

ctx as it stands abstracts the following.

- Process identity information - process_uuid, cmd_args etc.

- Volume specific information  - graph_id, list of graphs of a given volume,
  connection to volfile server, client_table etc.

- Aggregate of resources       - memory pools, event pool, syncenv (for
  synctasks) etc.

This proposal already does parts of above, i.e, to break the abstraction of an
aggregate of resources into a resource pool structure. I wouldn't decide on the
approach based on the no. of code (sites) that this change would impact. More
change is not necessarily bad.  I would decide on ease of abstraction and
extension it brings with it, for the kind of features that are to come in with
4.0. For e.g, imagine how this would pave way to enhance glusterfs to support
multiple (sub-)volumes being served from a single (virtual)brick process.This
is crudely similiar to multiple-'ctx' problem gfapi is trying to solve now.