pre-RFC: life-before-main / lib init

[dhardy]

Thanks for the feedback.

lazy_static is pretty useless for initialising a logger (see log and env_logger crates: the logger doesn’t initialise itself because it doesn’t know how it should be configured).

I know life-before-main is problematic in C++. My proposal fixes some of the problems: initialisation order is defined (deterministic), and nothing weird happens if exec X depends on A and B, which both depend on C which must have stuff initialised (see above: nothing transitive; X must init C directly). My proposal also ensures life-before-main is optional by allowing manual initialisation instead.

This proposal doesn’t try to address uses of globals before initialisation. This could be (partially) tackled with lifetime analysis but I’m not sure this is warranted. Note that this “problem” already exists in Rust: e.g. if you log a message before initialising the logger, the message is simply lost. This isn’t a big problem as long as things like Option are used instead of blindly dereferencing pointers.

But yes, a custom test driver allowing init-before-tests would solve my main motivation; the feature may not actually be needed.

[dhardy]

Here’s a workaround btw:

I think this kind of workaround would be needed even with my proposal, since it doesn’t allow initialisation in libraries.

[pcwalton]

Life-before-main is abused a lot in C++ and Go. I’m pretty wary of it.

[comex]

lazy_static is pretty useless for initialising a logger (see log and env_logger crates: the logger doesn’t initialise itself because it doesn’t know how it should be configured).

Can you elaborate? What in particular are you able to do from pre-main initializer function that you couldn’t do from a lazy_static initializer?

[jethrogb]

Can you elaborate? What in particular are you able to do from pre-main initializer function that you couldn’t do from a lazy_static initializer?

I think it goes something like this: your program Foo depend on library Bar which depens on library Logger. Foo does not depend directly on Logger. Logger’s functionality requires some sort of global state initialization. Therefore, before Bar can use Logger it needs to be initialized. I think in current Rust you have two options: 1) expose a Bar::init function that must be called by Foo before using anything else in Bar. 2) Access/initialize Logger in Bar through some lazy_static, but this would “contaminate” all usage sites.

However, I think it’s unlikely that Bar would know how Logger should be configured.

[yigal100]

Imho, the best design for such problems is indeed to provide a way to construct Bar and pass it the required dependencies (Also see, DI pattern).

Having global state and tight coupling with a specific implementation are not nice. What If the user of Bar wants to log using OtherLogger™ instead?

[comex]

I think it goes something like this: your program Foo depend on library Bar which depens on library Logger. Foo does not depend directly on Logger. Logger’s functionality requires some sort of global state initialization. Therefore, before Bar can use Logger it needs to be initialized. I think in current Rust you have two options: 1) expose a Bar::init function that must be called by Foo before using anything else in Bar. 2) Access/initialize Logger in Bar through some lazy_static, but this would “contaminate” all usage sites.

However, I think it’s unlikely that Bar would know how Logger should be configured.

Sure, this is a dilemma - but how would life-before-main help? If Bar or Logger used an #[init] function (as proposed here), that wouldn’t somehow help it know how it should be configured.

Is the issue the performance of lazy_static? Ideally in the fast path it should be a single (non-atomic) load plus a predictable branch, which might still be too slow in some extreme cases but is unlikely to show up here. Actually, looking at the logger implementation, it already does considerably more expensive stuff (an atomic increment) on every log attempt, regardless of whether logging is enabled.

[dhardy]

Well, if Foo uses Bar which uses Logger, and Logger needs initialisation… then there are three ways of doing this:

1. Foo calls some init function on Bar which calls an init function in Logger
2. Logger uses lazy_static to initialise itself
3. Foo calls an init function in Logger directly

Option 2 would work fine if no parameters need to be passed but isn’t much good if it needs configuration from anywhere other than environment variables. The log crate BTW doesn’t configure where it logs to, but relies on other crates like env_logger to control where it logs, and these may require run-time variables to be passed (e.g. name of a log file). So option 2 is not always a good choice.

Option 1 works in the case above. But imagine Foo also uses another library, Baz, and that Baz also uses Logger. If Foo calls Bar’s init and Baz’s init and both of these try to initialise Logger, then Logger gets initialised twice. Of course it could handle this gracefully, but then if Bar and Baz try to initialise it in different ways it’s not clear what will happen. Or Foo could not call Baz’s init, but then what if Baz needs to initialise other things? So option 1 is not ideal.

This leaves option 3. Option 3 requires a little more work from the end user, but avoids the above issues so may well be the best option. That’s why I choose this solution for the RFC above.

[dhardy]

Can you elaborate? What in particular are you able to do from pre-main initializer function that you couldn’t do from a lazy_static initializer?

Take a look at the log crate. The simple logger here doesn’t need any parameters, but imagine a variant logging to a file. Where is that file name going to come from? It could be hard-coded, it could come from an environment variable, or it could be determined dynamically, e.g. by looking for other log files in a few standard locations or by reading a configuration file.

[withoutboats]

I think you’ve forgotten to include some information in your RFC. You are describing a feature in which my code can pass dynamic arguments to an “init” function from a lib, but your RFC shows init functions being triggered by adding an #[init] tag to an extern crate declaration. Its not at all clear to me how I would pass arguments to an init function in logger.

I think everyone understands the motivation you are describing, but not how your RFC achieves it.

[withoutboats]

I’m very strongly against the idea of declaring a guarantee that these functions will be called in the ‘source order’ of your code. Source order is semantically significant in macro_rules! macros, and this is considered one of their most damning flaws, which is why they will some day be deprecated. This makes far too many changes that should be totally irrelevant ‘breaking changes,’ because they could reorder init functions.

[dhardy]

Thanks withoutboats, that’s the kind of feedback needed.

I see your point about not wanting to depend on source order. The simplest (and probably best) way out of this is to only allow one init function per crate (which also makes arg-passing easier to handle).

About parameter passing: you’re spot on. Constants could perhaps be passed as arguments before main, but this is limited. I would not want to derive dynamic arguments before main. This only leaves one possibly-useful option: arguments which can be passed statically (something clumsy like #[init(args=("path/to/log_file.log"))], or dynamically (by calling the init function from main or later instead of using #[init]).

At this point, init-before-main seems a little less useful, since it just moves a function call from main to a use extern ... attribute. The exception being test-drivers where we don’t (currently) have a main.

[withoutboats]

I think maybe there’s a bit of an XY problem here. You’ve identified a set of related problems (lazy static initializers can’t really be passed arguments, we can’t define an initializing set up function for test runner code right now) and proposed life before main as the solution. I think there are probably other more targeted solutions (e.g. some sort of tag for test set up functions for the test runner) that don’t introduce as many problems as life before main would.

[mehcode]

I implemented this pre-RFC in a crate: https://crates.io/crates/init

I added the restriction of one init function per crate.

Any libraries just need

#![feature(proc_macro)]

extern crate init;

use init::init;

#[init]
fn init() {
  // [...]
}

Binaries can have their own init and can add any library inits

#![feature(proc_macro)]

extern crate init;

// Pretend nom has an init
#[init]
extern crate nom;

use init::init;

#[init]
fn init() {
  // [...]
}

fn main() {
}

Binaries additionally need a build.rs file. Note that this part could have be done a few other ways but since if this RFC is adopted it wouldn’t need to exist I figured it doesn’t matter much how its done in this crate.

extern crate init;

fn main() {
    init::build();
}

[vi0]

Relevant: https://github.com/mmastrac/rust-ctor

[josh]

C++ pre-main global constructors, and the ELF ctors section, have been a major source of headache. I don’t think we should recreate that in Rust.

Among other things, dlopen of a shared library calls constructors.

[vi0]

typetag, one of recent “crates of the week”, depends on ctor and with missing ctor calls you may suddenly get deserialization problems, I expect.

Can this example (a TWiR-approved crate that uses ctor) start C++-esque tradition of relying on life-before-main?

[Ixrec]

@dtolnay I couldn’t find anything in the docs for typetag, inventory or ctor on why any of this needs to be implemented with life-before/after-main instead of making the client app write something like typetag::init() in main().

Is the life-before-main stuff “just” to enable writing libraries that don’t virally “infect” all transitive dependents and their client apps with a need to explicitly init() the library in main()? Could this be controlled by cargo features? Is the inadequacy of cargo features for transitive dependency config (ping @kornel) a factor here? etc.

[dtolnay]

I intend to switch it from inventory to linkme which does not involve ctors or any dynamic initialization.

[kornel]

Cargo features are separate from Rust language features, and Cargo can’t nicely set language features (overriding compiler flags for the entire build is a blunt tool), so there’s a hypothetical inadequacy, but I don’t think that’s the reason.

Not having code before main is a very useful property for a low level language.

It means it’s easily interoperable with C. It means it can be used in a static library linked with any other programming language. It means it can work easily as a dynamic library used as a plug-in in lots of native software, and in all these cases every function you export from Rust will just work.

If Rust could depend on some global code automagically run outside of main, then it could break if that magic isn’t always properly set up. It would mean that externally calling some random Rust function (from C, from other language’s FFI, from plug-in host) could hit Rust by surprise in a semi-uninitialized state with broken globals.

OP’s motivation: running env_logger::init() for every test is a real problem. BUT I think it’s better to solve that one with test frameworks that have setup and teardown, without adding a potentially problematic feature to the entire language:

eRFC: Custom test frameworks