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

[Cyrill Gorcunov via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

On Sun, Aug 08, 2021 at 05:34:54PM +0300, Vladislav Shpilevoy wrote:
> >> 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.
> 
> I didn't propose to drop the locking. I said it could be hidden
> inside of the limbo's API. In the only example above you show:
> 
> >       txn_limbo_term_lock
> >         txn_limbo_replica_term_locked
> >       txn_limbo_term_unlock
> 
> Here the lock is done inside of the limbo's API too. It is
> not exposed on the limbo's API level. So the questions is the
> same - can it be hidden inside of the API? Are there any usages
> of the lock done explicitly out of the limo?

Actually, everything start looking a way more unattractive I think.
Lets gather the current API from the patchset.

applier_synchro_filter_tx
  txn_limbo_is_replica_outdated
    txn_limbo_term_lock
      txn_limbo_replica_term_locked
    txn_limbo_term_unlock

box_demote | box_promote_qsync | box_promote
  txn_limbo_replica_term
    txn_limbo_term_lock
      txn_limbo_replica_term_locked
    txn_limbo_term_unlock


wal_stream_apply_synchro_row | box_issue_promote | box_issue_demote | memtx_engine_recover_synchro
  txn_limbo_process
    txn_limbo_term_lock
      txn_limbo_filter_locked
      txn_limbo_process_locked
    txn_limbo_term_unlock

apply_synchro_row
  txn_limbo_term_lock
    txn_limbo_filter_locked
    ** in-callback apply_synchro_row_cb -> txn_limbo_process_locked
  txn_limbo_term_unlock

Thus we have:

 - big txn_limbo_process function which operates with locked promote term
 - txn_limbo_replica_term inliner, which relies on txn_limbo_term_lock/unlock
   being present in header file
 - txn_limbo_is_replica_outdated inliner, which relies on lock/unlock being
   exported as well

and apply_synchro_row as a special one which uses txn_limbo_process_locked
internally when commit happens. Note that all the functions above use explicit
lock/unlock inside single function, and even apply_synchro_row calls lock at
start and unlock at exit.

Now if I gonna hide locking completely from usage ouside of limbo code I
have to:

1) Move txn_limbo_term_lock/txn_limbo_term_unlock into .c file, in result
   txn_limbo_is_replica_outdated and txn_limbo_replica_term won't be
   inliner anymore. Which is not critical I think but better to point out.
2) We inroduce txn_txn_limbo_process_begin/complete/rollback which are basically
   the wrappers arount txn_limbo_process_locked (because txn_limbo_process
   will remain as is). Thus we will have

txn_txn_limbo_process_begin()
  txn_limbo_term_lock()
  txn_limbo_filter_locked();

txn_txn_limbo_process_complete()
  txn_limbo_process_locked()
  txn_limbo_term_unlock

txn_txn_limbo_process_rollback
  txn_limbo_term_unlock

And these three helpers looks very ugly. First of all they hide locking
unlocking between functions, since there is no explicit lock/unlock
in apply_synchro_row anymore. Do you really prefer this kind of
design, or I miss something obvious?

	Cyrill