On 24/08/2016, Casey Bodley wrote:
[snip]
> The next step is to prevent global_init()/common_init()/CephContext from
> doing any work in the parent process (esp. spawning threads for Log,
> CephContextServiceThread, and AdminSocket). Decoupling the config parsing
> from CephContext initialization seems like a natural way to accomplish that.
> So the parent would create and initialize the md_config_t object, then after
> fork, the child would pass that as an argument when creating the
> CephContext.
>
> How does that sound for a start?
I'm very much in favor of the decoupling idea. If we did that we could
simply not create the CephContext at all until after the fork.
--
Senior Software Engineer Red Hat Storage, Ann Arbor, MI, US
IRC: Aemerson@{RedHat, OFTC, Freenode}
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
