[Tarantool-patches] [PATCH v10 2/4] limbo: order access to the limbo terms

[Vladislav Shpilevoy]

Thanks for the patch!

> diff --git a/src/box/applier.cc b/src/box/applier.cc
> index f621fa657..9db286ae2 100644
> --- a/src/box/applier.cc
> +++ b/src/box/applier.cc
> @@ -856,7 +856,7 @@ apply_synchro_row_cb(struct journal_entry *entry)
>  		applier_rollback_by_wal_io(entry->res);
>  	} else {
>  		replica_txn_wal_write_cb(synchro_entry->rcb);
> -		txn_limbo_process(&txn_limbo, synchro_entry->req);
> +		txn_limbo_process_locked(&txn_limbo, synchro_entry->req);
>  		trigger_run(&replicaset.applier.on_wal_write, NULL);
>  	}
>  	fiber_wakeup(synchro_entry->owner);
> @@ -867,11 +867,13 @@ static int
>  apply_synchro_row(uint32_t replica_id, struct xrow_header *row)
>  {
>  	assert(iproto_type_is_synchro_request(row->type));
> +	int rc = 0;
>  
>  	struct synchro_request req;
>  	if (xrow_decode_synchro(row, &req) != 0)
>  		goto err;
>  
> +	txn_limbo_term_lock(&txn_limbo);

Maybe you should hide the lock from the API. Instead, do similar to
what transactions do:

	int txn_limbo_process_begin(limbo *);
	void txn_limbo_process_commit(limbo *, request *);
	void txn_limbo_process_rollback(limbo *);

begin would take the lock, commit would do the request and
unlock, rollback would only unlock. Commit and rollback you
call from apply_synchro_row_cb depend in on the WAL write
result.

Then the locks would disappear from the API, right?

In the next patch you would make txn_limbo_process_begin()
also take the request to validate it. Then the 'filtering'
would become internal to the limbo.

>  	struct replica_cb_data rcb_data;
>  	struct synchro_entry entry;