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.Roy@xxxxxxxxxxx> 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:aemerson@xxxxxxxxxx] > Sent: Thursday, December 03, 2015 9:25 AM > To: Somnath Roy > Cc: Sage Weil; Samuel Just (sam.just@xxxxxxxxxxx); ceph-devel@xxxxxxxxxxxxxxx > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
