On Tue, Jun 30, 2020 at 10:46:54PM -0500, Rob Hoelz <r...@hoelz.ro> wrote: > That would work, but wouldn't that potentially break users' extensions by > getting rid > of global destruction time? For example, if a user did something like this:
No, because a) perl doesn't guarantee calling destructors on process exit and b) perl corrupts data structures at this stage, so it's not a reliable mechanism in any case. (See e.g. http://blog.schmorp.de/2015-11-12-tidbits-why-coro-crashes-or-how-perl-6-deals-with-bugs.html). > ...the clean up code in the guard would never run, right? Yes, but IMnsHO that's better than if it were to run only sometimes, and lead to crashes at other times, but it all seemed to work during development. > Also, if any *other* library decided to call getenv in an exit handler, > the segfault would pop up again. The solution could be further optimised by calling _exit, leading to even faster exit times. > on the details of the copying and swapping of the environment that > rxvt-unicode does (I'm > guessing it has to do with urxvtd), but is there a way the code could be > modified to restore > environ to a valid pointer before main() returns? Possibly. But anything added makes things bigger and slower, and this must be offset by a tangible gain. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ rxvt-unicode mailing list rxvt-unicode@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
