From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 14 Jun 2019 11:05:07 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] [PATCH v3 07/14] wal: remove fiber from a journal_entry structure Message-ID: <20190614080507.qg6deptmwe6s5xhy@esperanza> References: <20190613141702.rd2el6drnu7keku5@esperanza> <1927249.GYfve5z4RM@home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1927249.GYfve5z4RM@home.lan> To: =?utf-8?B?0JPQtdC+0YDQs9C40Lkg0JrQuNGA0LjRh9C10L3QutC+?= Cc: tarantool-patches@freelists.org List-ID: On Thu, Jun 13, 2019 at 10:33:37PM +0300, Георгий Кириченко wrote: > > Using a fiber_cond to wake up a single fiber is an overkill. You could > > as well do > > > > while (!entry->done) > > fiber_yield_timeout(TIMEOUT_INFINITY); > It is not even possible. In common case (an asynchronous transaction for > instance) WAL doesn't know which fiber should be awaken and even does such > fiber exist. Please consider following case: an applier fired a transaction and > died. Transaction is finished and could be finalized in any fiber which possible > doesn't exist in this time. So the one way I see do handle this is to let fiber > subscribe on transaction done. If you could offer me with better solution I > would be happy. It would be nice to see this reasoning in a comment to the code. However, I don't quite agree. An applier fires async transactions, which it doesn't really need to wait for, as we can free async transactions right from the completion callback. To stop the applier on WAL error we could use on_rollback trigger AFAICS. Regarding sync transactions, we can make the fiber waiting for it to complete non-cancellable, just like we do now.