gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Consider phasing out GNUNET_SERVICE_MAIN


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Consider phasing out GNUNET_SERVICE_MAIN
Date: Sat, 7 Sep 2019 15:06:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

On 9/7/19 1:51 PM, Alessio Vanni wrote:
> Hello,
> 
> 3rd-party applications often require a particular initialization, for
> example localization or even just a custom version string.  Currently,
> clients can solve some of these situations by calling `GNUNET_OS_init'
> in their `main' function, before `GNUNET_PROGRAM_run' (anything else not
> covered by GNUNET_OS_ProjectData is left to the application itself.)
> 
> For services, however, it is not as simple: the `GNUNET_SERVICE_MAIN'
> macro completely hides the `main' function, so it's impossible to call
> `GNUNET_OS_init' and the like.  The macro could be expanded manually
> (i.e. use an explicit `main' rather than the macro), but
> `GNUNET_SERVICE_run_' has a name that, by convention, denotes a private
> function that should not be used directly.
>
> I suggest to make the `GNUNET_SERVICE_run' public, so that applications
> can run their initialization procedures before the service "connects"
> with GNUnet.
> 
> In theory this change would only require to change "run_" to "run" and
> rewrite the gnunet-ext service accordingly.  There's no need to outright
> remove the macro as it can be used internally without problems.

Replacing the macro would destroy a planned future feature (aka "GNUnet
as a library").  So I'm not exactly for this.  Using "run_" for code
that "really" knows what it's doing is something I'd consider
acceptable, but in this case there seems to be a better alternative: use
a C constructor to call GNUNET_OS_init():

/**
 * Initialize i18n
 */
void __attribute__ ((constructor)) i18n_init () {
  GNUNET_OS_init (...);
}

Constructors run before main(), so that should fix your problem nicely.

> In the meantime, the attached patch adds localization to services.
> Until now, even if the locale is changed, any message printed by a
> service would not be translated regardless of what the relevat PO file
> contains.

Looks reasonable, patch applied. Thanks!


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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