This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't close or flush stdio streams on abort
- From: Rich Felker <dalias at aerifal dot cx>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Wed, 8 May 2013 18:22:50 -0400
- Subject: Re: [PATCH] Don't close or flush stdio streams on abort
- References: <mvm4ned3jja dot fsf at hawking dot suse dot de> <20130508101232 dot GA21001 at domone> <mvmr4hh1xxr dot fsf at hawking dot suse dot de> <20130508172315 dot GA20323 at brightrain dot aerifal dot cx> <20130508215126 dot GA23387 at domone dot kolej dot mff dot cuni dot cz>
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
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