307325 - PR_AttachThread is strange as it ignores some params on windows

Status: NEW

(NSPR :: NSPR, defect)

Description

[timeless]

nspr-95 built using seamonkey trunk from last week.

nspr4!PR_AttachThread [r:\mozilla\nsprpub\pr\src\threads\combined\pruthr.c @ 
1506]
attach!AttachDetach+0x28 [r:\mozilla\nsprpub\pr\tests\attach.c @ 108]
attach!Measure+0x10 [r:\mozilla\nsprpub\pr\tests\attach.c @ 129]
attach!threadStartFunc+0xf [r:\mozilla\nsprpub\pr\tests\attach.c @ 156]
MSVCR71!_endthreadex+0xa0
kernel32!BaseThreadStart+0x37

Comment 1

[Wan-Teh Chang]

timeless: your bug description is too terse for me
to understand.

PR_AttachThread is implemented.  It is done in the
PR_GetCurrentThread call.

PR_DetachThread is now a no-op and the thread detachment
is done in the DLL_THREAD_DETACH handler in the DllMain
function of nspr4.dll:
http://lxr.mozilla.org/nspr/source/nsprpub/pr/src/md/windows/w95dllmain.c#60

There is a bug open to restore the old implementation
of PR_DetachThread -- to detach the thread right there.

Comment 2

[timeless]

an explanation that PR_AttachThread doesn't support random attachment of call 
stacks and that it is a stub would be sufficient. brendan explained how this 
stuff works, but redaing the code it looked really strange, and it's clear that 
you can't get PR_AttachThread to honor one of its parameters, so it would have 
helped me if there was a comment about it.... feel free to mark this bug 
invalid.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.