To be clear, I'm ok with having a queue_transaction which takes a Transaction by value and moves it into a dynamic unique_ptr controlled instance, but I don't want the filestore passing a naked pointer around internally with a flag indicating whether it needs to be deleted by the filestore. If there is an actual user which requires the transaction to stick around afterwards *and* cannot afford to copy it, then we can talk about a design which accomplishes that. -Sam
On Thu, Dec 3, 2015 at 9:50 AM, Samuel Just <sj...@redhat.com> wrote: > 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
