This is the mail archive of the libc-ports@sources.redhat.com 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]

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


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

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]