On Mon, Aug 21, 2023 at 11:43:32AM -0400, Mathieu Desnoyers wrote: > 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 ?
The replacement is liburcu-mb, correct? I will need to change perfbook, but that should be an easy change, plus sys_membarrier() is widely available by now. Thanx, Paul _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev