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

[Mike Frysinger <vapier at gentoo dot org>]

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
-mike

Attachment: pgp00000.pgp
Description: PGP signature