Re: [RFC PATCH 20/23] vinyl: use cbus for communication between scheduler and worker threads

[Vladimir Davydov <vdavydov.dev@gmail.com>]

On Tue, Jul 31, 2018 at 11:43:42PM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [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.