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.
--
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
