As far as I know, there are no current users which want to use the Transaction later. You could also change apply_transaction to copy the Transaction into a unique_ptr since I don't think it's used in any performance sensitive code paths. -Sam
On Thu, Dec 3, 2015 at 9:48 AM, Somnath Roy <somnath....@sandisk.com> wrote: > Yes, that we can do..But, in that case aren't we restricting user if they > want to do something with this Transaction object later. I didn't go through > each and every part of the code yet (which is huge) that are using these > interfaces to understand if it is using Transaction object afterwards. > > Thanks & Regards > Somnath > -----Original Message----- > From: Adam C. Emerson [mailto:aemer...@redhat.com] > Sent: Thursday, December 03, 2015 9:25 AM > To: Somnath Roy > Cc: Sage Weil; Samuel Just (sam.j...@inktank.com); ceph-devel@vger.kernel.org > Subject: Re: queue_transaction interface + unique_ptr + performance > > On 03/12/2015, Somnath Roy wrote: >> Yes, I posted the new result after adding -O2 in the compiler flag and it >> shows almost no overhead with unique_ptr. >> I will add the test of adding to list overhead and start implementing the >> new interface. >> But, regarding my other point of changing all the objecstore interfaces (my >> first mail on this mail chain in case you have missed) taking Transaction, >> any thought of that ? >> Should we reconsider having two queue_transaction interface ? > > As I understand it, the concern with switching to unique_ptr was that the > callee would move from the reference without this being known to the caller. > > Would it make sense to pass as an RValue reference (i.e. TransactionRef&&)? > That way the compiler should demand that the callers explicitly use std::move > on the reference they're holding, documenting at the site of the call that > they're willing to give up ownership. > > > -- > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
