Statics destruction orders

I asked a question today in Stack Overflow: Why does an atexit handler panic when it accesses stdout?

This arises when I found out that you can not println when dropping Log because of this.
This seems to me to be the question of destruction order of statics.
Do we already have consensus on how we should do it? Is there any reason to have different queues for those handlers?

  1. Rust does not have "life after main". When I hit a similar issue, standard output was a thread-local, not a global, so it was destroyed in LIFO order on thread termination. That probably doesn't help, though.
  2. The simplest way to solve your problem is probably to go down a level and call libc::write or equivalent. That's valid anywhere, even in a signal handler (on Unix; I don't remember the Windows rules).

I think it's fine to bear with order dependency problem of initialization.

What I am concerned with now is log crate, which is in nursery right now, uses different queue from the std. This makes the order problem more complicated. Not only you need to worry about the relative position in each queue, now you also have to be careful about the relative positions of queues.

For this specific case, libc::atexit seems to be invoked later than the sys_common::at_exit. This means the logger is destructed later than stdout. Although both logger and stdout are legitimate static variables. stdout seems to be lower level than logger.

It should be easy to implement tactic solution for the problem at hand, but I would like to try do the thing in the right way. I think it would be nice to

  1. Implement a recommended-to-use method to destruct static variable. This can be either kind of queue, but we need a way for user to reasonable the exact sequence of restructuring.
  2. Consider establishing an order of std static, and put them in the lowest level so that they have long enough time to live to wait for other statics to destruct.

In the current case maybe to expose some form of atexit or lazy, and use them consistently both in and out of std.