[tarantool-patches] Re: [PATCH 1/7] Refactoring: wal writer fiber and queue

["Георгий Кириченко" <georgy@tarantool.org>]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

On Friday, August 16, 2019 4:53:32 PM MSK Konstantin Osipov wrote:
> * Georgy Kirichenko <georgy@tarantool.org> [19/08/13 10:30]:
> > As wal processes all writes in a cbus loop fiber it isn't possible to
> > yield while write. The patch introduces a wal write queue and a wal write
> > fiber which fetch a batch from queue and writes it out. Also checkpoint
> > requests are going now throw the queue to synchronize a tx checkpoint
> 
> though
> 
> > status with wal.
> 
> I don't understand this patch.
> 
> First, WAL already runs in a fiber, and you can yield.
wal could not yield because the same fiber processes cbus events. So there is 
no chance to wake this fiber up because there is no running fiber to process 
cbus input.
> 
> cord_costart creates a new fiber, please check out the implementation.
> 
> this is done by this commit:
> 
>     commit f4625e64eb99c17910d3f0bcd323e5d82b6d5b31
>     Author: Vladimir Davydov <vdavydov.dev@gmail.com>
>     Date:   Wed Jul 4 20:20:55 2018 +0300
> 
>     vinyl: use cbus for communication between scheduler and worker threads
> 
>     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.
> 
>     Needed for #2129
> 
> Check out the commit, it changes cord_start() to cord_costart().
> 
> 
> Second, checkpoint message already flushed the queue. So I don't
> understand why you need a switch over message type.
> 
> Let's discuss online.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 488 bytes --]