Re: Load GNUnet's plugins even when ProjectData is different (patch)

[Christian Grothoff]

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