Re: [PATCH] abort: Only flush file-based stdio streams before termination

[Carlos O'Donell <carlos at redhat dot com>]

On 08/17/2017 09:59 AM, Florian Weimer wrote:
> On 08/17/2017 03:45 PM, Carlos O'Donell wrote:
>> On 08/17/2017 09:35 AM, Florian Weimer wrote:
>>> Historically, glibc flushes streams on abort, which is not
>>> required by POSIX.  This can trigger additional work
>>> (including callbacks through function pointers) in processes
>>> which are known to be in a bad state.  After this change,
>>> only streams which are backed by the standard descriptor-based
>>> implementation are flushed.
>>
>> Does this mean open_memstream streams to NVM won't be flushed by
>> default?
> 
> You can't put open_memstream streams on NVM because their backing
> storage is tied to the malloc allocator.

The allocator is user interposable.

>> As a user I might be convinced that my own custom streams need to
>> flushed by hand in an abort handler, but I might expect open_memstream
>> streams to be flushed.
> 
> Flushing open_memstream streams prior to process termination is not
> observable, except via an abort handler.  I don't think we need to flush
> them.

It is observable if you back the allocations onto NVM.

It is conceivable to do so for a robust application that has to journal
state and recover after a crash.

My opinion is that we should flush memory streams, but I'm not firmly
entrenched in this opinion.

I admit the NVM example is contrived, but using NVM in a case like this
is exactly what *I* would use NVM for.

I'm OK with this change if we clearly document what we're doing in the
glibc manual, and explain the alternative solution of flushing from the
abort handler.

The downside to signal handling to flush streams is that signal actions
are not easily composable and therefore rely on the various library
authors coordinating in some kind of compositional way to handle abort
cleanup.

-- 
Cheers,
Carlos.