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

[Martin Schanzenbach]

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