Not sure why you'd want to RadosClient instances to share outgoing threads etc. Seems like a bad idea to me. Allen Samuels SanDisk |a Western Digital brand 2880 Junction Avenue, San Jose, CA 95134 T: +1 408 801 7030| M: +1 408 780 6416 allen.samuels@xxxxxxxxxxx > -----Original Message----- > From: Adam C. Emerson [mailto:aemerson@xxxxxxxxxx] > Sent: Friday, June 10, 2016 1:43 PM > To: Allen Samuels <Allen.Samuels@xxxxxxxxxxx> > Cc: Gregory Farnum <gfarnum@xxxxxxxxxx>; The Sacred Order of the Squid > Cybernetic <ceph-devel@xxxxxxxxxxxxxxx> > Subject: Re: A Transformation of our Global Context > > On 10/06/2016, Allen Samuels wrote: > > Have you considered threadlocal storage for this? I suspect it's a > > *much* easier way to go. Very little source code will need modification. > > I thought about it briefly, but I don't think it would work for tools that spawn > two RadosClients each pointing to a different cluster. While each would > launch threads of its own, they'd both share the application threads for > outgoing operations (at least until they hit the messenger). So I think we'd > still need to tease apart the class somewhat to make thread local storage > work. > > -- > 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 ��.n��������+%������w��{.n����z��u���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
