Re: [lttng-dev] [RFC] Deprecating RCU signal flavor

[Mathieu Desnoyers via lttng-dev <lttng-dev@lists.lttng.org>]

On 8/15/23 08:38, Mathieu Desnoyers via lttng-dev wrote:
> On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
>>
>> After discussing it with Mathieu, we agree on the following 3 phases for
>> deprecating the signal flavor:
>>
>>   1) liburcu-signal will be implemented in term of liburcu-mb. The only
>>   difference between the two flavors will be the public header files,
>>   linked symbols and library name.  Note that this add a regression in
>>   term of performance, since the implementation of liburcu-mb adds memory
>>   barriers on the reader side which are not present in the original
>>   liburcu-signal implementation.
>>
>>   2) Adding the deprecated attribute to every public functions exposed by
>>   the liburcu-signal flavor.  At this point, tests for liburcu-signal
>>   will also be removed from the project.  There will be no more support
>>   for this flavor.
>>
>>   3) Removing the liburcu-signal flavor completely from the project.
>>
>> Finally, here is a tentative versions release of mine for each phase:
>>
>>   1) 0.15.0 [October 2023] (also TSAN support yay!)
>>
>>   2) 0.15.1
>>
>>   3) 0.16.0 || 1.0.0 (maybe a major bump since this is an API breaking
>>   change)
> 
> There is a distinction between the version number of the liburcu project 
> (0.14) and the ABI soname for the shared objects. We may be able to do 
> step (3) without going to 1.0.0 (I don't see removal of the urcu-signal 
> flavor a strong enough motivation for hitting 1.0.0 yet).
> 
> Technically speaking, given that we would be removing the entire 
> liburcu-signal.so shared object, we would not be changing _symbols_ 
> within an existing shared object, therefore I'm not even sure we need to 
> bump the soname for all the other remaining shared objects.

So after merging this commit:

     Phase 1 of deprecating liburcu-signal
     
     The first phase of liburcu-signal deprecation consists of implementing
     it in term of liburcu-mb. In other words, liburcu-signal is identical to
     liburcu-mb at the exception of the function symbols and public header
     files.
     
     This is done by:
     
       1) Removing the RCU_SIGNAL specific code in urcu.c
     
       2) Making the RCU_MB specific code also specific to RCU_SIGNAL in
       urcu.c
     
       3) Rewriting _urcu_signal_read_unlock_update_and_wakeup to use a
       atomic store with CMM_SEQ_CST instead of a store CMM_RELAXED with
       cmm_barrier() around it. We could keep the explicit barriers, but that
       would require to add some cmm_annotate annotations. Therefore, to be
       less intrusive in a public header file, simply use the CMM_SEQ_CST
       like for the mb flavor.

I notice that an application previously built against urcu-signal with
_LGPL_SOURCE defined would have to be rebuilt, which would require a
soname bump of urcu-signal.

So considering that this phase 1 is not really a "drop in" replacement,
I favor removing the urcu-signal flavor entirely before the next release.

Thoughts ?

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev