Re: should CephContext be a singleton?

[Jeff Layton <jlayton@redhat.com>]

On Wed, 2017-09-13 at 11:30 -0400, Adam C. Emerson wrote:
> On 13/09/2017, John Spray wrote:
> [snip]
> > The separation between process global stuff and per-cluster stuff
> > still seems entirely sensible, I don't know how much progress was made
> > with that for the RGW/RBD bits that have cluster-spanning daemons?
> 
> As I understand it, people agreed on getting rid of g_ceph_context but
> not on separation, but if people like separation....
> 
> But! Either way, the other advantage of getting rid of g_ceph_context
> is that it makes embedding potentially multiple daemons in processes
> and clears up other librarification issues. (For example, if we ever
> wanted to try client-side erasure coding, the g_ceph_context in the
> ErasureCode library might be a problem.)
> 
> Sage also worried about logging and the problem of marking messages
> from multiple OSDs in a single process and making sure they went to
> the appropriate files and so on. I had an idea for keeping the
> per-process context and logging thread-local and simulating dynamic
> scoping on top of it to address the logging problem, but that was
> thought to be too complicated and people liked just passing it around
> instead.
> 
> 
> > I was wondering about this the other day, does std::mutex give us the
> > cycle detection some other way?  lockdep is a seriously useful thing.
> 
> Well! If you want lockdep, there's common/mutex_debug.h which plugs
> into lockdep. You could insert it anywhere you wanted to use lockdep
> or have more run-time checking.
> 

Fair enough, and thanks for all the input. At this point, I've pretty
much determined that the main problem in that tracker bug is with
lockdep.

I'm going to opt for smaller, more targeted surgery that should keep
things working more or less as they are, but close the races that can
occur when the cct is unregistered from lockdep while other threads are
concurrently manipulating mutexes. That has the advantage of being
relatively easy to backport too, I think.

I should have a PR up in a day or two, once I do some more testing with
the series.

Thanks!
-- 
Jeff Layton <jlayton@redhat.com>