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

[Mike Frysinger]

i was going through the list of functions which may be cancellation endpoints:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_05_02

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 ?

perhaps this would even be too much:
 } else {
+	pthread_descr self = thread_self();
+	int oldstate = THREAD_GETMEM(self, p_cancelstate);
+	THREAD_SETMEM(self, p_cancelstate, PTHREAD_CANCEL_DISABLE);
 	tm.tv_sec = 0;
 	tm.tv_nsec = SPIN_SLEEP_DURATION;
 	nanosleep(&tm, NULL);
+	THREAD_SETMEM(self, p_cancelstate, PTHREAD_CANCEL_ENABLE);
 	cnt = 0;
 }
or mayhaps a new internal function __pthread_setcancelstate_nocancel() ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-ports/attachments/20061025/0a370ee0/attachment.sig>