On Sun, 2020-12-13 at 16:23 +0100, Christian Grothoff wrote: > Hi Alessio, > > The idea is good, but I dislike two details: > > 1) GNUNET_PLUGIN_load_all_default should be a function, not a macro; > 2) It should be "load_all_with_context" > and we should give it the "GNUNET_OS_ProjectData" > to use as an argument, i.e.: > > GNUNET_PLUGIN_load_all_with_context ( > GNUNET_OS_project_data_default(), ...) > > would do exactly what your code does. > > IMO, that pattern is more widely usable. > > Also, we should consider making the 'context' a thread-local (which, > if > unset, is set from a corresponding global?) so that these operations > remain thread-safe. Martin, WDYT?
Agreed > > -Christian > > On 12/13/20 3:41 PM, Alessio Vanni wrote: > > Hello, > > > > the attached patch is an extended version of [0], as at the time I > > didn't realize that e.g. re:claimID also loads plugins the same > > way. > > > > As explained both in the linked discussion and in the commit > > message, > > when the ProjectData structure is not GNUnet's default one (i.e. > > any > > third-party application not included in GNUnet's distribution) the > > lazy-loading of plugins will search for them in the application's > > paths > > instead of GNUnet's. > > > > This patch only affects the parts using `GNUNET_PLUGIN_load_all', > > so > > those functions using `GNUNET_PLUGIN_load' are still affected by > > the > > bug; however, a quick search shows that the latter function is used > > in > > places that, under normal circumstances, do not interact with the > > application's ProjectData (for example, TRANSPORT or ATS startup), > > so > > there shouldn't be any immediate issue. > > > > Thanks, > > A.V. > > > > [0] > > https://lists.gnu.org/archive/html/gnunet-developers/2020-07/msg00049.html > > >
signature.asc
Description: This is a digitally signed message part
