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: Thu, 9 May 2013 18:24:30 -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> <20130508222249 dot GG20323 at brightrain dot aerifal dot cx> <20130509075104 dot GA26255 at domone dot kolej dot mff dot cuni dot cz> <20130509135313 dot GH20323 at brightrain dot aerifal dot cx> <20130509195408 dot GA2038 at domone dot kolej dot mff dot cuni dot cz>
On Thu, May 09, 2013 at 09:54:08PM +0200, OndÅej BÃlka wrote:
> On Thu, May 09, 2013 at 09:53:13AM -0400, Rich Felker wrote:
> > On Thu, May 09, 2013 at 09:51:04AM +0200, OndÅej BÃlka wrote:
> > > 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.
> >
> > The easiest way to do this is by taking the lock...
> >
> Which can lead deadlock, which this patch tries to avoid.
See above; the proposal was that it could be done with a trylock. Then
there is no possibility of deadlock because the thread calling abort
never waits for a lock before the process terminates.
Rich