Open
Bug 301986
Opened 19 years ago
Updated 2 years ago
pthread_t cannot always be used as NSPR thread ID
Categories
(NSPR :: NSPR, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: mi+mozilla, Unassigned)
References
(Blocks 1 open bug, )
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.4; FreeBSD; X11; amd64) KHTML/3.4.1 (like Gecko)
Build Identifier:
The thread_id is assumed, for some reason, to be a 32-bit value. This is not
true on 64-bit systems. There is a special type for thread-ids and that is what
should be used.
Reproducible: Always
Reporter | ||
Comment 1•19 years ago
|
||
Comment 2•19 years ago
|
||
This is a real bug, but we can't use your proposed fix.
PR_GetThreadID is supposed to return a NSPR thread ID
that is a 32-bit unsigned integer and that may not be
related to the pthread or native thread ID.
The correct fix is for NSPR to create and maintain a
32-bit unsigned thread ID, rather than casting pthread_t
to PRUint32.
Because of this bug, PR_GetThreadID is not usable. That's
one reason it is a "private" (but exported) function.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: pthread_t is not always 32-bit wide → pthread_t cannot always be used as NSPR thread ID
Reporter | ||
Comment 3•19 years ago
|
||
=The correct fix is for NSPR to create and maintain a
32-bit unsigned thread ID
Why can't it be a 64-bit value on 64-bit systems?
=rather than casting pthread_t to PRUint32.
My fix is not suggesting that. I suggest using pthread_t wherever thread ID is
used. If need be, a PRThreadType or something can be introduced (which will be
the same as pthread_t on pthread-using systems).
Updated•18 years ago
|
QA Contact: wtchang → nspr
Reporter | ||
Comment 4•15 years ago
|
||
This bug is 5 years old. What's holding it up? Why is anyone worried for ABI-compatibility (on 64-bit systems), that would be broken by the proposed change, if the existing code never worked on 64-bit systems anyway>
(In reply to Mikhail Teterin from comment #4)
> This bug is 5 years old. What's holding it up? Why is anyone worried for
> ABI-compatibility (on 64-bit systems), that would be broken by the proposed
> change, if the existing code never worked on 64-bit systems anyway>
I suppose, patch should be updated and review flag set as explained in https://developer.mozilla.org/En/Developer_Guide/How_to_Submit_a_Patch#Getting_reviews
It should block bug 512076.
Blocks: 512076
Updated•2 years ago
|
Severity: normal → S3
Comment 8•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: wtc → nobody
Status: ASSIGNED → NEW
You need to log in
before you can comment on or make changes to this bug.
Description
•