From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D0A3C30EFE for ; Thu, 20 Jun 2019 16:35:03 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QS362PkpVi5 for ; Thu, 20 Jun 2019 16:35:03 -0400 (EDT) Received: from smtp14.mail.ru (smtp14.mail.ru [94.100.181.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 8C1F930ECD for ; Thu, 20 Jun 2019 16:35:03 -0400 (EDT) From: =?utf-8?B?0JPQtdC+0YDQs9C40Lkg0JrQuNGA0LjRh9C10L3QutC+?= Subject: [tarantool-patches] Re: [PATCH v4 4/9] txn: get rid of fiber_gc from txn_rollback Date: Thu, 20 Jun 2019 23:35:00 +0300 Message-ID: <3842834.7Xb97VBgmu@home.lan> In-Reply-To: <20190620074318.GD15155@atlas> References: <0eeb7c2b0e45bfae1cba4488292c7d6fc7e69fa4.1560978655.git.georgy@tarantool.org> <20190620074318.GD15155@atlas> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2626532.LbSAHiJgCI"; micalg="pgp-sha256"; protocol="application/pgp-signature" Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Konstantin Osipov Cc: tarantool-patches@freelists.org --nextPart2626532.LbSAHiJgCI Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Thursday, June 20, 2019 10:43:18 AM MSK Konstantin Osipov wrote: Accepted, I will restore all fiber_gc > * Georgy Kirichenko [19/06/20 09:54]: > > Don't touch a fiber gc storage on a transaction rollback explicitly. > > This relaxes dependencies between fiber and transaction life cycles. > > As discussed verbally, LGTM. > > > --- a/src/box/applier.cc > > +++ b/src/box/applier.cc > > @@ -190,7 +190,7 @@ apply_initial_join_row(struct xrow_header *row) > > > > fiber_gc(); > > return rc; > > > > rollback: > > - txn_rollback(); > > + txn_rollback(txn); > > > > return -1; > > > > } > > I weighed your argument that an error leads to diag_raise(), which > ends the running fiber, so fiber_gc() is unnecessary. This is > true, but don't you think it is a change in the protocol between > the caller and the callee? What should be this protocol generally > now that we moved most of memory allocation into txn? What should > is fiber gc useful for, and should the user always use it with > savepoints perhaps? > > While we're thinking about it and inspecting all of the code to > use txn gc if at all possible, please add a comment that > fiber_gc() will be called by the caller since we expect the error > to abort it. Actually whichever you prefer -a comment or a > fiber_gc(). I prefer fiber_gc(), until we replace it with an > assert that fiber gc is not used in this function. > > > @@ -334,7 +336,7 @@ apply_wal_row(struct xstream *stream, struct > > xrow_header *row)> > > } > > if (box_process_rw(&request, space, NULL) != 0) { > > > > say_error("error applying row: %s", request_str(&request)); > > > > - txn_rollback(); > > + txn_rollback(txn); > > > > diag_raise(); > > the same argument is here. please either add a comment or not > change the protocol between the caller and the callee and leave > fiber_gc() in place. Tomorrow the error may be suppressed for > whatever reason, and we may start having growing garbage on fiber > gc pool. Honestly, until we add fiber_gc() to every fiber yield or > use another system-wide mechanism to ensure it never grows out of > control, I don't think it's safe to remove it from such places. > > Fusing fiber memory and txn memory had one advantage: we had at > leasat some certainty that a fiber which executes transaction will > free its memory on a regular basis. Now there is no certainty at > all. > > With these two minor comments the patch is LGTM. --nextPart2626532.LbSAHiJgCI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEFB+nbqWGnp59Rk9ZFSyY70x8X3sFAl0L7fQACgkQFSyY70x8 X3uqZggAj93FeCYCdzyJZ4xzLZ7ZJciaIyk8AsIpjZFDeQlqPbWFwham3MqVD0QW owYSZvZgmRPE0SaGBotkFtlQ5styQ2e1On86iFJE0eC3htGyU1L+2bvwkrJXJAkl jTeg7p27JxfebiN7PJL+RNk9ZIS8Zq5bucvBjoj0Ak6v/TqwxPDrNujbq4k5B+GD DNyGfaWZPynWiH1isIfFuIhABWwXaxyxaRaT+0EIMbj04gaKocLswSSwbNROaquc g0AqzWB4Fv/BgjR5pq6wsGFJxqeQ8MkSVE6U1x7ENwnpqJBVEGGc0HmnHZYw8f+e c1MqE9LpVemISAUekvBGU678pdh3Qw== =6RWL -----END PGP SIGNATURE----- --nextPart2626532.LbSAHiJgCI--