On 13/09/2017, Jeff Layton wrote:
> It contains stuff like admin sockets, and certain threads are tied to
> it, etc. This seems like the sort of thing that should just have a
> single instance per process. Should we start moving things in that
> direction, or should I look at fixing this another way?
There was a general consensus of removing use of the g_ceph_context
variable. A PR of mine removed it from the object store, OSD and
messenger, though other things needed doing so I haven't got around to
removing the rest.
If you have the cycles for it, feel free to start removing it from
elsewhere and threading CephContext* in.
There isn't really a consensus on splitting out CephContext so it's
less of a God Object but it might be worth reconsidering that at some
point.
Also the lockdep stuff may be less of an issue as we move away from
Mutex to std::mutex. (Though I do have a debugging mutex class that
lets people into our lockdep code if we find that is an issue. I
/suspect/ something like helgrind might be better for finding lock
ordering errors.)
--
Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@{RedHat, OFTC}
0x80F7544B90EDBFB9 E707 86BA 0C1B 62CC 152C 7C12 80F7 544B 90ED BFB9
--
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
