pthread_t cannot always be used as NSPR thread ID

ASSIGNED
Assigned to

Status

NSPR
NSPR
ASSIGNED
12 years ago
3 years ago

People

(Reporter: Mikhail T., Assigned: Wan-Teh Chang)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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

12 years ago
Created attachment 190369 [details] [diff] [review]
Use pthread_t for thread-ids
(Assignee)

Comment 2

12 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

12 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). 
QA Contact: wtchang → nspr
(Reporter)

Comment 4

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

Comment 5

6 years ago
(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

Comment 6

5 years ago
It should block bug 512076.

Updated

5 years ago

Updated

3 years ago
Duplicate of this bug: 953413
You need to log in before you can comment on or make changes to this bug.