On Wed, 22 Jul 2026 at 08:03, Paul Eggert <[email protected]> wrote: > > On 2026-07-19 10:21, Luca Boccassi wrote: > > On Sat, 18 Jul 2026 at 07:46, Paul Eggert <[email protected]> wrote: > >> > >> For this one, two general issues: > >> > >> * This implementation doesn't appear to be thread-safe. > > > > Switched to using the 'once' module > > Many programs that Gnulib's selinux-h module are single-threaded. There > should be some way for them to use selinux-h without also dragging in > the 'once' module. Bruno may be able to help here, as he knows more > about multithreading.
Isn't that a huge footgun to leave lying around otherwise? There shouldn't be an extra cost to just always using it, as some years ago glibc merged the separate pthread library anyway, so it's no longer a separate component. Modules having dependencies on other modules seems relatively commonplace? > > It doesn't make a lot of sense for each function to do its own dlsym, > > as the common dlopen object is needed anyway, so might as well set up > > all symbols immediately. > > Although that's true for some applications, it's not true for all. > Whether it makes sense to call dlsym eagerly depends at least in part on > the application's preferred style for linking. As I understand it wget2, > octave, and libvirt defer calling dlsym until a symbol is needed, at > least for some symbols. I am pretty sure and willing to bet that this is all i/o bound anyway, and the dominating cost, assuming it's even measurable, is loading the shared object from disk. > > An explicit initialization seems overkill, > > libselinux has implicit global state anyway, it doesn't operate only > > on explicit caller-owned objects, so it makes things more complex and > > annoying to use, for little benefit. > > Hmm, my intuition is just the opposite, namely, since libselinux has > global state the application needs to be somewhat careful in messing > with that state, and so needs a way to configure libselinux safely in a > single thread before letting Having to remember to synchronize two layers of global state would be a gigantic pain for consumers, as this class of problems is generically speaking one of the gnarliest to have to deal with, especially when it's so trivial to make it safe in all cases. Basically it pushes a large complexity to users in order to save a tiny amount of implementation details, I'm pretty sure it is not a worthy tradeoff. > >> What if the app has libselinux linked in for other reasons, before > >> 'main' even starts? Would that collide with the draft patch? That is, > >> does the draft patch insist that Gnulib be the only way to use > >> libselinux functionality? > > Any word on this? Would the patch cause libselinux to be linked twice? > I'm a bit fuzzy on the details. Sorry missed it - if the library is already loaded by the loader, then dlopen et al. become no-ops as far as I know and have seen, and the already-loaded object is just used transparently. > >> Why depend on stddef-h? > > > > For the definition of NULL > > I would think that every stddef.h in a Gnulib porting target already > defines NULL well enough for selinux-h. A dependency on stddef-h is > needed only if selinux-h would otherwise run afoul of the problems noted > in doc/posix-headers/stddef.texi, problems that Gnulib fixes. > > Admittedly this is a minor point. The coreutils build yelled at me without it, so it seems not
