GNOME Bugzilla – Bug 134119
Improve pthread "priority scheduling" detection
Last modified: 2011-09-30 04:30:35 UTC
The gthread-posix.c file defines the HAVE_PRIORITIES macro based on the existence of PTHREAD_{MIN,MAX}_PRIORITY macros. If this gets defined, the code assumes later that the functions pthread_attr_{get,set}schedparam exist. This is wrong, and will lead to build problems on some versions of NetBSD (I've filled this bug as "All" operating systems, since I expect problems in other platforms). The solution is simple: aside from checking for the existance of PTHREAD_{MIN,MAX}_PRIORITY, the code should also check for _POSIX_THREAD_PRIORITY_SCHEDULING, a macro which must be defined by the threading implementation if it supports priority scheduling. The attached patch was done by Matthias Scheler for NetBSD, based on a suggestion from Nathan J. Williams.
Created attachment 24306 [details] [review] Sample patch for gthread/gthread-posix.c
Sebastian, can you look at this ?
The problem here is: Can we assume, that all POSIX/DCE implemetations with thread priorities do define _POSIX_THREAD_PRIORITY_SCHEDULING. I think (I haven't found anything about that though) that at least on DCE this isn't true. So the right solution for GLib would be to test for pthread_attr_set_schedparam and pthread_setprio in configure.in. That however would further inflate configure.in, which I'm not very fond of. So I thought, I would wait, until the bug would disapear all by itself. "It's only a moment for eternity, waiting would serve no purpose though". That didn't work out, it seems. I'll have a look. Should be quite straightforward (and ugly). As we had no other reports so far, the other possibility would be to specifically test for NetBSD and only ask for _POSIX_THREAD_PRIORITY_SCHEDULING there. Dunno.
Uh... I wonder why I didn't reply before. Anyway, patching it so that this constant is only checked under NetBSD is fine with me, though it is not the cleanest solution: another system (if any) may have the same problem but not benefit from the fix. However, if adding a check to the configure script is not possible, it may be the only solution. I've just checked and there is no AC_CHECK_FUNCS call after pthread is detected, so it's not possible to re-use an existent one (if not moved) to check for these functions... the script could effectively grow a bit. Whichever way, I feel this issue should be resolved.
Can you provide a patch to check for pthread_attr_set_schedparam and pthread_setprio in configure.in ?
No patch appeared, closing.
Created attachment 58869 [details] [review] New patch. This should do it.
Hmm, I only see pthread_setschedprio in my pthread.h, not pthread_setprio, so maybe checking for pthread_setprio is not a good idea. Neither of these functions seem to be used in gthread-posix.c anyway. Sebastian ?
code dealing with priorities has been removed