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