From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 1 Aug 2018 17:26:34 +0300 From: Vladimir Davydov Subject: Re: [RFC PATCH 20/23] vinyl: use cbus for communication between scheduler and worker threads Message-ID: <20180801142634.dppf524viff4wdbj@esperanza> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180731204342.GI15235@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Tue, Jul 31, 2018 at 11:43:42PM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [18/07/08 22:53]: > > We need cbus for forwarding deferred DELETE statements generated in a > > worker thread during primary index compaction to the tx thread where > > they can be inserted into secondary indexes. Since pthread mutex/cond > > and cbus are incompatible by their nature, let's rework communication > > channel between the tx and worker threads using cbus. > > OK to push. > > > + /** > > + * Fiber that is currently executing this task in > > + * a worker thread. > > + */ > > + struct fiber *fiber; > > You could consider using a fiber pool rather than starting a fiber > for each task, but I guess it's minor. Yep, thought about that too. It could simplify the code a little bit. But we don't really need a fiber pool here. Besides, fiber pool has some troubles with thread termination IIRC - currently we can't just make a thread using a fiber pool stop immediately without waiting for existing fibers to terminate (we don't want to wait for compaction to complete if tarantool is stopped). I'll look into this. > > Have you benched the performance of this patch? I would expect it > to have some positive impact on performance. Alas, there's no performance benefit, because dump/compaction are very rare operations and they take really long (seconds, minutes sometimes). That is the pthread mutex that guards the task queue is taken so infrequently that you can't even feel it. There's no lock contention or other problems usually associated with locks either.