Re: [V2 patch] Enhance comments in nsswitch.h

[DJ Delorie <dj at redhat dot com>]

Florian Weimer <fweimer@redhat.com> writes:
> But that doesn't seem true for e.g. service_user objects in the current
> framework because threads traverse the list without locking.  We cannot

They key phrase here is "in the current framework".  Also in the current
framework, we don't reload nsswitch.conf.  We'd like to reload it.  That
means changing the code and dealing with these issues.  Analyzing the
objects that might need to be reloaded is merely the first step.

> trivially add locking because we keep pointers service_user objects
> across calls to NSS module functions, which can block for a long time.

Yup.  Perhaps we could temporarily have two configs running in parallel
until the old calls all finish.

> That's true for all data structures right now.  However, we shouldn't
> dlclose any DSOs because they might not be prepared to be unloaded.

Yeah, the idea was the DSO stuff would stick around, just the
nsswitch.conf rules would change.

> I think the high-level question for me is whether this
> can-be-deallocated property is a property of the struct member (where
> you documented it in the patch), or a property of the type.  For
> example, it seems to me that all name_database_entry objects can be
> reloaded.  Maybe there is value in keeping this simple and not share
> data too much?

Since I used "ptr-to-foo" my intent is to reflect if that pointer may
change across an nsswitch reload or not, which is the key information we
need to understand before changing code.  Indirectly, that implies which
types are reloadable, and the independent comments group those types
into persistent vs reloadable.

Part of the persistent-vs-reloadable stuff also comes from trying to
understand what information was actually stored in each type :-) For
example, we have a tree that maps API functions to DSO functions (the
"void *known;").  It's currently part of the nsswitch data, but the
mapping is DSO-specific.  We could move that map to the DSO data if we
accept that the map may contain more entries and thus increase
processing time but reduce memory cost.