[Tarantool-patches] [PATCH v2 1/2] box: refactor in_promote using a guard
Cyrill Gorcunov
gorcunov at gmail.com
Wed May 26 10:25:54 MSK 2021
On Tue, May 25, 2021 at 01:39:28PM +0300, Serge Petrenko wrote:
> ---
> src/box/box.cc | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/src/box/box.cc b/src/box/box.cc
> index c10e0d8bf..894e3d0f4 100644
> --- a/src/box/box.cc
> +++ b/src/box/box.cc
> @@ -1562,6 +1562,9 @@ box_promote(void)
> int rc = 0;
> int quorum = replication_synchro_quorum;
> in_promote = true;
> + auto promote_guard = make_scoped_guard([&] {
> + in_promote = false;
> + });
Looks ok to me, though I must confess I always consider such
flags spread all over the code is somehow clumsy. Since this
is a common pattern in our cpp code lets keep it but still in
my humble opinion we could rather move all box_promote code
into some box_do_promote helper and we would have
int
box_promote(void)
{
static bool in_promote = false;
if (in_promote) {
diag_set(ClientError, ER_UNSUPPORTED, "box.ctl.promote",
"simultaneous invocations");
return -1;
}
in_promote = true;
int rc = box_do_promote();
in_promote = false;
return rc;
}
but surely this is not a request for code refactoring, current form
is ok as well ;)
Ack.
Serge, while you're at this code anyway, could you please change
switch (box_election_mode) {
case ELECTION_MODE_OFF:
try_wait = true;
break;
...
default:
panic("enexpected box_election_mode mode");
break;
}
instead of unreacheable() call. We should stop using unreacheable()
as much as we could.
More information about the Tarantool-patches
mailing list