From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kirichenkoga@gmail.com>
Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com
 [209.85.167.66])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 468FE452566
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 14 Nov 2019 17:06:39 +0300 (MSK)
Received: by mail-lf1-f66.google.com with SMTP id q28so5162247lfa.5
 for <tarantool-patches@dev.tarantool.org>;
 Thu, 14 Nov 2019 06:06:39 -0800 (PST)
From: Georgy Kirichenko <kirichenkoga@gmail.com>
Date: Thu, 14 Nov 2019 17:06:36 +0300
Message-ID: <13232148.CanJsBF7IP@home.lan>
In-Reply-To: <20191114134422.GA8372@atlas>
References: <20191114125705.26760-1-maria.khaydich@tarantool.org>
 <20191114134422.GA8372@atlas>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [Tarantool-patches] [PATCH] Trigger on vclock change
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Konstantin Osipov <kostja.osipov@gmail.com>
Cc: tarantool-patches@dev.tarantool.org

On Thursday, November 14, 2019 4:44:22 PM MSK Konstantin Osipov wrote:
> * Maria <maria.khaydich@tarantool.org> [19/11/14 15:59]:
> > This patch implements replication.on_vclock
> > trigger that can be  useful for programming
> > shard-systems with redundancy.
> 
> 3808 is about being able to wait for an lsn.
> 
> Using a trigger for *waiting* is called busy waiting, and is a cpu
> hog, especially at a performance critical space like update of
> replica vclock, which can happen a hundred times a second.
> 
> Why not implement a way to wait for an lsn instead?
Please explain your proposal in a more detailed way.
Do you wish to implement a hard-coded `handler` and each time when a replica 
vclock is updated this handler will compare the updated vclock against members 
of set of replica_id:lsn pairs organized in a list, tree or something else? 
And if a compare matches to true then a corresponding handler will be called?

Anyway, we will need to have such trigger in order to make applier able to 
report local replica wal and commited vclock in scope of synchronous 
replication issue.