This is the mail archive of the mailing list for the libc-ports project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: incorrect usage of cancellable nanosleep() in __pthread_acquire() ?

On Wednesday 25 October 2006 08:41, Daniel Jacobowitz wrote:
> On Wed, Oct 25, 2006 at 06:11:39AM -0400, Mike Frysinger wrote:
> > and noticed that nanosleep() is in there but pthread_mutex_lock() is not
> > ... so, since pthread_mutex_lock() is implemented on top of
> > __pthread_lock() which is implemented on top of __pthread_acquire() which
> > calls nanosleep(), isnt this a not-so-good idea ?  the huge comment block
> > above
> > __pthread_acquire() explains why this is necessary, and considering we
> > have to do all this ugly scheduling in userspace while nptl does it in
> > kernel space, i guess there's no way around it ?
> Before I even look any closer at these reports, what's the point?

in the case of this second e-mail wrt nanosleep(), there really isnt much 
point ... if the issue i raised in the previous e-mail was resolved, this 
second one would certainly be ignorable

> LinuxThreads is nothing even vaguely like POSIX compliant.  It's never
> claimed to be, and at this late date it certainly never will be.

that's pretty much how i look at it as well ... i only want to try and fix 
bugs that people find rather than go looking for ones myself

in the case of the other e-mail, the POSIX misbehavior is causing a customer's 
application to crash as they [rightly] assume the cleanup functions wont be 
run more than once

Attachment: pgp00000.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]