`#[dtor]` does not match semantics of `#[ctor]`

[melvyn2]

Registering a function with atexit does not really match what I would expect from this crate/attribute. I would expect that, like __attribute__((destructor)), the function is called at module unload time, which could occur at a different time than actual program exit.

[mmastrac]

Most likely dtor will be disappearing in a 1.0 release as it's been finicky to get working. I just need some time to get around to doing that major release.

[mmastrac]

FWIW I'd be open to a discussion of the future of the API, but I think it is difficult to get this working cross-platform.

[melvyn2]

for *bsd and linux, link_section = ".fini_array" should work (haven't tested yet), and __DATA,__mod_term_func works for macos. I can't find a corresponding section for windows (though I haven't looked far), but it certainly is possible with DllMain.

[CGMossa]

I was banking on dtor-functionality :(

[mmastrac]

For ctor 1, I'm going to split the dtor functionality out into its own crate, where we can experiment with different design decisions.

I've create a placeholder crate for dtor for now, published from this repo: https://crates.io/crates/dtor

[CGMossa]

Thanks! Somehow, I encountered an inconsistency that made me drop the whole idea (that includes using dtor), but I still think there is room for dtor as a whole.

[sylbeth]

Am I right to think, for running on dylib unload, that the atexit function should work for Windows, link_section = ".fini_array" for Linux and link_section = "__DATA,__mod_term_func" for MacOS and this hasn't been developed yet, right?

[mmastrac]

The dtor library is in the process of being split out -- unfortunately Apple has decided to deprecate __mod_term_func, so there's no clearly supported method on all platforms. We previously used that approach, but switched to atexit-style dtors a few years back because of the platform mismatches.

Given the variety of methods, dtor will likely end up with a configurable shutdown method but cxa_atexit is probably the most reliable.

[mmastrac]

Note that dtor is probably going to be less of my focus moving forward, so if you'd like to work on that API, feel free!

I expected that it'll look something like this:

#[dtor] // use the automatic implementation per-platform
#[dtor(atexit)] // use a ctor that installs an atexit handler
#[dtor(...)] // tbd ctor-link syntax for link sections

[sylbeth]

Given the variety of methods, dtor will likely end up with a configurable shutdown method

That does make sense.

cxa_atexit is probably the most reliable.

It still works on MacOS and is valid for Linux too, right? In Windows atexit should still work for unloading.

Note that dtor is probably going to be less of my focus moving forward

Is that because it is harder to maintain than ctor?

if you'd like to work on that API, feel free!

Then, may I make a pr once I understand the code fully? I haven't work with proc macros yet so my head is having a hard time understanding for now.

[mmastrac]

@sylbeth

Then, may I make a pr once I understand the code fully? I haven't work with proc macros yet so my head is having a hard time understanding for now.

Sounds good! If you'd like to propose the syntax you'd suggest for dtor, we can work out the best way to implement it ahead of time to clarify things.

[sylbeth]

Sounds good! If you'd like to propose the syntax you'd suggest for dtor, we can work out the best way to implement it ahead of time to clarify things.

Alright! I need some days to get back home and make another pr first, then I'll take a look and after thinking it out properly propose something before coding it, if that is good for you.

[sylbeth]

Just thought that maybe the api could allow for people to choose an implementation per target.

So something like:

#[dtor] Default implementation, probably unload of shared library or program termination if no unloading

#[dtor(termination)] Always program termination, the default implementation for it

#[dtor({implementation}] Specified implementation for all targets

#[dtor({target}={implementation}, …) Specified implementation for specific target (overrides any choice for all targets for that specific target).

What things are allowed or not in dtor functions may also be important to document?

[mmastrac]

@sylbeth

#[dtor({target}={implementation}, …) is likely not necessary, because we can use ![cfg_attr(target=..., dtor(...))] for those cases.

I think we may want to flesh out the methods a bit. termination a good idea, though I'd suggest we shorten it to term. This would give us:

• (default) - nothing specified, use the most reliable method per platform which would be at the discretion of the library, ie: #[dtor] which would be somewhat equivalent to #[cfg_attr(target_vendor="apple", dtor(__cxa_atexit)] #[cfg_attr(not(target_vendor="apple"), dtor(term))]
• term - use a link section, optional arg to specify: #[dtor(term, link_section="my_fini_section").
• atexit - explicit libc::atexit in a ctor. Optional ctor(...) arg for custom ctor placement and other args: dtor(atexit, ctor(link_section="my_link_section"))
• __cxa_atexit - shared library friendly termination. Optional ctor(...) arg as above.

How does this look?

[sylbeth]

Sorry for the late reply, had it half replied and lost it and things have been kind of hectic.

#[dtor({target}={implementation}, …) is likely not necessary, because we can use ![cfg_attr(target=..., dtor(...))] for those cases.

You are absolutely right about that, didn't think of it, so that solves it.

I think we may want to flesh out the methods a bit.

Agreed

I'd suggest we shorten it to term.

I think that's fine, yeah, can't be confused with terminal since nothing here interacts with it, but I still think termination is more explicit and easy to understand.

the most reliable method per platform

Here I don't fully agree, I think either the default is a best effort to run on program termination (no matter if it's unloaded) or on dynamic library unload. We could do as you said and make the default the most reliable implementation but I'd say wanting "on dylib unload" or "on program termination" are mostly invariant between platforms, so we could either make one of those the default and the other be #[dtor(unload)]/#[dtor(term/termination)], or the default be most reliable and then you can specify.

term - use a link section

Why would it use a link section? I think atexit is better for "program termination only", for example, for Linux

atexit - explicit libc::atexit in a ctor. Optional ctor(...) arg for custom ctor placement and other args: dtor(atexit, ctor(link_section="my_link_section"))
__cxa_atexit - shared library friendly termination. Optional ctor(...) arg as above.

I think this would be sufficient yes.

I think, then, the options would be as follows:

• #[dtor]: Most reliable option for every platform
• #[dtor(term/termination)]: Best effort to run ONLY on program termination
• #[dtor(unload)]: Best effort to run at library unload (/ termination in case there is no unloading)
• #[dtor(atexit[, ctor(link_section="my_link_section")])]: atexit function in a ctor at link section if provided, if not best known section.
• #[dtor(__cxa_atexit[, ctor(link_section="my_link_section")])]: Same as previous but just for __cxa_atexit
• #[dtor(link_section)]: Simply links a function to the best known link section, that would be .fini_array on Linux, for example.
• #[dtor(link_section="my_link_section")]: Same as before, only specifying the link section to be the one chosen.

What do you think of what I said?