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? -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: OpenPGP digital signature
