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@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
