[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Grothoff
Subject: Re: Load GNUnet's plugins even when ProjectData is different (patch)
Date: Sun, 13 Dec 2020 16:23:19 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

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?


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]

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]