Re: [PATCH] Don't close or flush stdio streams on abort

[OndÅej BÃlka <neleai at seznam dot cz>]

On Wed, May 08, 2013 at 06:22:50PM -0400, Rich Felker wrote:
> On Wed, May 08, 2013 at 11:51:26PM +0200, OndÅej BÃlka wrote:
> > > With the right types of locks, a trylock operation could be performed
> > > instead of waiting for a lock. This requires an async-signal-safe,
> > > reentrant, recursive mutex.
> > 
> > It is most elegant solution but not only way. My comment 
> > was that when you stop other threads and block signals then writing if 
> > they are unlocked can be done with any type of lock. You also do not 
> > worry to unlock correctly as program ends. (Overkill but possible.)
> 
> You mean you want to stop all other threads, then forcibly steal their
> locks? This is not valid. The state protected by the lock need not be

No. I want to stop threads to stop them trying to take locks. When lock
is held do nothing.

> consistent. You might end up writing the same data twice, or perhaps
> even writing totally bogus data. This could result in data corruption
> bugs (if a file is open for update and writing twice writes past one
> record and into the next record) or possibly (not sure) information
> leaks. Such behavior is non-conforming. abort() is allowed (but not
> required) to flush open FILEs, but it can't arbitrarily corrupt them
> or perform other unwanted actions on them.
> 
> Making stealing the lock safe may be possible, but would be extremely
> difficult. It would require analyzing the program counter in stopped
> threads to determine whether pending writes had completed.
> 
> Rich