Re: [RFC] libgfortran dll i/o redirection lossage caused by order-of-termination issue

[Dave Korn <dave dot korn dot cygwin at googlemail dot com>]

Dave Korn wrote:
> Corinna Vinschen wrote:
>> Hi Dave,
>>
>> On Jul 20 16:05, Dave Korn wrote:
>>> Christopher Faylor wrote:
>>>
>>>>>  That's with the Cygwin DLL simply patched to schedule an atexit call to
>>>>> dll_global_dtors directly after the exe's global dtors get run.
>>>> So, you've removed the call from do_exit() then?  If so, please also remove the
>>>> ES_GLOBAL_DTORS definition.
>>>   Not yet.  Wanted to see what happens if I leave it in there as a last-chance
>>> fallback.
>> Any news?  A patch, maybe?

>   I appear to have worked around my BLODA for the moment and have a testrun
> progressing nicely now, with g++ completed and java nearly done.  Let's wait
> and see how the libstdc++ tests go, sometime tomorrow.

  So, the tests all finished successfully, in c++ and java, which I think is
pretty good validation of the safety of this change.  I'm in two (possibly even
three) minds about what to do now:


1- Ship it!  Commit it as it stands, dll_global_dtors is idempotent so it
doesn't matter if it gets called again during ES_GLOBAL_DTORS.

2- Remove ES_GLOBAL_DTORS, because we believe that the outcome of the various
standards is that dtors only get run if you exit() and not if you _exit() or
abort().

3- ????


  I guess we ought to look at #2, but that's going to require a bunch more
testing.  'Safe' though the idea of a last-chance to call the dtors may sound, I
could perhaps imagine a code where dtors take some action that the application
would specifically be trying to avoid; e.g. maybe renaming a temp output file
into place on top of an existing generated file which should only be done if the
entire output file was generated successfully.

  So, I'll start on that after I've had a few hours sleep and a chance to
consider any suggestions anyone comes up with between now and then.  It's
getting light outside...

    cheers,
      DaveK