On Fri, Aug 26, 2022 at 10:34 AM Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > > On 26/08/22 19:05, Ian Rogers wrote: > > On Fri, Aug 26, 2022 at 3:37 AM Adrian Hunter <adrian.hunter@xxxxxxxxx> wrote: > >> > >> On 24/08/22 18:38, Ian Rogers wrote: > >>> Switch to the use of mutex wrappers that provide better error checking. > >>> > >>> Signed-off-by: Ian Rogers <irogers@xxxxxxxxxx> > >>> --- > >>> tools/perf/util/dso.c | 12 ++++++------ > >> > >> Some not done yet > >> > >> $ grep -i pthread_mut tools/perf/util/dso.c > >> static pthread_mutex_t dso__data_open_lock = PTHREAD_MUTEX_INITIALIZER; > >> pthread_mutex_lock(&dso__data_open_lock); > >> pthread_mutex_unlock(&dso__data_open_lock); > >> if (pthread_mutex_lock(&dso__data_open_lock) < 0) > >> pthread_mutex_unlock(&dso__data_open_lock); > >> pthread_mutex_unlock(&dso__data_open_lock); > >> pthread_mutex_lock(&dso__data_open_lock); > >> pthread_mutex_unlock(&dso__data_open_lock); > >> pthread_mutex_lock(&dso__data_open_lock); > >> pthread_mutex_unlock(&dso__data_open_lock); > > > > Yes, these are all solely dso__data_open_lock that lacks any clear > > init/exit code to place the initialization/destruction hooks onto. I > > don't plan to alter these in this patch set. > > Perhaps that could be explained in the change log. > > But why not just add init / exit code. Could be called out > of main(), or maybe use __attribute__((constructor)) / > __attribute__((destructor)) Because the lock is global and not part of the dso. Thanks, Ian
