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

[Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

On 09.08.2021 19:24, Cyrill Gorcunov wrote:
> 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?

They look consistent with txn_begin/commit/rollback. They hide the locking,
exactly. This is what I wanted to achieve, because I don't like that
the applier interferes into the limbo so hard. Yes, I would prefer this API.
Lets wait for Sergey's opinion too.