Closed Bug 756047 Opened 8 years ago Closed 5 years ago

Fix _POSIX_THREAD_PRIORITY_SCHEDULING detection

Categories

(NSPR :: NSPR, defect, P1)

All
OpenBSD
defect

Tracking

(Not tracked)

RESOLVED FIXED
4.10.8

People

(Reporter: gaston, Assigned: gaston)

Details

Crash Data

Attachments

(1 file, 1 obsolete file)

According to http://www.cognitus.net/html/howto/pthreadSemiFAQ_5.html (still looking for the real posix spec mentioning it), _POSIX_THREAD_PRIORITY_SCHEDULING should not only be checked for being defined but also > 0. Since OpenBSD switched to kernel threads we temporarly don't provide working thread priority functions, so that #define  _POSIX_THREAD_PRIORITY_SCHEDULING is -1. 

We currently patch ptthreads.c accordingly, see http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/nspr/patches/patch-mozilla_nsprpub_pr_src_pthreads_ptthread_c?rev=1.5
See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/unistd.h.html :

"If a symbolic constant is not defined or is defined with the value -1, the option is not supported for compilation. If it is defined with a value greater than zero, the option shall always be supported when the application is executed. If it is defined with the value zero, the option shall be supported for compilation and might or might not be supported at runtime."

"_POSIX_THREAD_PRIORITY_SCHEDULING
The implementation supports the Thread Execution Scheduling option. If this symbol is defined in <unistd.h>, it shall be defined to be -1, 0, or 200809L. The value of this symbol reported by sysconf() shall either be -1 or 200809L. "
Another option of course is to replace all occurences of 

#if defined(_POSIX_THREAD_PRIORITY_SCHEDULING)

by

#if defined(_POSIX_THREAD_PRIORITY_SCHEDULING) && _POSIX_THREAD_PRIORITY_SCHEDULING > 0
Comment on attachment 624690 [details] [diff] [review]
check that _POSIX_THREAD_PRIORITY_SCHEDULING is > 0, #undef it otherwise

>+#if defined(_POSIX_THREAD_PRIORITY_SCHEDULING) && !(_POSIX_THREAD_PRIORITY_SCHEDULING > 0)

We can write

  #if defined(_POSIX_THREAD_PRIORITY_SCHEDULING) && (_POSIX_THREAD_PRIORITY_SCHEDULING <= 0)

right?  If defined(_POSIX_THREAD_PRIORITY_SCHEDULING) is true, then it is safe to
compare _POSIX_THREAD_PRIORITY_SCHEDULING for equality to 0.

If you can find the description of _POSIX_THREAD_PRIORITY_SCHEDULING in a POSIX or
Single Unix Specification page, please let me know.  Thanks.
gaston: Ah, I didn't see your comment 2.  Thanks.
I looked at how NSPR uses _POSIX_THREAD_PRIORITY_SCHEDULING.
It seems that NSPR expects not only the functions exist at
compile time, but also the functions work when executed.
I saw assertions that the relevant pthread functions return 0,
and I saw no handling of sched_get_priority_min() and
sched_get_priority_max() failures (returning -1).

So, I think that we can replace all occurences of

#if defined(_POSIX_THREAD_PRIORITY_SCHEDULING)

by simply

#if _POSIX_THREAD_PRIORITY_SCHEDULING > 0

This is simpler than your suggestion in comment 3.  This
replies on that fact that an undefined macro gets the value
0L in a C-preprocessor conditional expression.
Well, your call, but as the symbian case already used the way to #undef the sym that's why we've reused the same. But both ways should work. I'm not  100% sure relying on the fact that an undef macro gets a 0L value is very obvious.. What happens if it's explicitely #undef'ed ? it gets 0L anyway ?
Any news regarding that ? can we move this issue forward ? I've stumbled upon it again when updating our port of nspr to 4.9.2.
Crash Signature: dfzfsdfsdfsd
I've encountered this problem myself and ended up with a patch almost identical to the attached, but any of these proposed solutions seem straightforward to implement.  Is there anything in particular still holding up this bug?
Attachment #624690 - Flags: review?(ted)
The C99 spec says: "After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0" (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf 6.10.1 Conditional inclusion, step 4)
Comment on attachment 624690 [details] [diff] [review]
check that _POSIX_THREAD_PRIORITY_SCHEDULING is > 0, #undef it otherwise

As much as I sympathize with your desire to get this landed, Wan-Teh expressed that he preferred the > 0 solution, so if you can provide that patch I can review and land it for you.
Attachment #624690 - Flags: review?(wtc)
Attachment #624690 - Flags: review?(ted)
Assignee: wtc → landry
Attachment #624690 - Attachment is obsolete: true
Attachment #8536733 - Flags: review?(ted)
Attachment #8536733 - Flags: review?(ted) → review+
http://hg.mozilla.org/projects/nspr/rev/1fcea1618bb7
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Priority: -- → P1
Hardware: Other → All
Target Milestone: --- → 4.10.8
Attachment #8536733 - Flags: review+
You need to log in before you can comment on or make changes to this bug.