Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Dec 1999 17:59:00 -0500 (EST)
From:      Daniel Eischen <eischen@vigrid.com>
To:        "Richard Seaman, Jr." <dick@tar.com>
Cc:        jasone@canonware.com, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Possible libc changes to support LinuxThreads
Message-ID:  <Pine.SUN.3.91.991209175143.20673A-100000@pcnet1.pcnet.com>
In-Reply-To: <19991209164854.E782@tar.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 9 Dec 1999, Richard Seaman, Jr. wrote:

> On Thu, Dec 09, 1999 at 05:41:09PM -0500, Daniel Eischen wrote:
> > Richard Seaman, Jr. wrote:
> > > Actually, I don't think all that many apps use pthread_cancel().
> > > Its kind of messy to use.  Most can get along without it, which
> > > is why there have only been a limited number of complaints about
> > > the lack of pthread_cancel() in libc_r (until recently).  BTW,
> > > I haven't looked at libc_r's new cancellation functions.  How do
> > > they avoid propagating cancellation points in libc without
> > > changing libc?  Maybe they have an idea that can be used here?
> > 
> > Hi Richard,
> > 
> > Libc_r doesn't avoid propagating cancellation points.  A read()
> > from within a libc(_r) function will still be a cancellation
> > point.
> 
> Hmm..
> 
> What happens with (for example) fread() ?
> 
> fread, in the thread safe version, can be:
> 
>    lock FILE pointer
>    read
>    unlock FILE pointer
> 
> If fread is a cancellation point, don't you end up with
> the lock held still?  Or, I guess since you keep track of
> lock owners you can unwind the locks if the thread cancels?

Yes, we keep track of all internal locks and release them when
the thread is cancelled.  The only think not released just yet
are standalone (not part of other locks, like file, mutex,
condvar, etc) spinlocks.  For instance the spinlock that protects
malloc() wouldn't be released.  It's easy enough to fix those
with setting/clearing of lock wanted flags and/or held lock
counts, but I'd thought I'd try to borrow a trick from the
SA paper.

Dan Eischen
eischen@vigrid.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.991209175143.20673A-100000>