[Webkit-unassigned] [Bug 22614] Need to add Win32 implementation of ThreadSpecific.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Dec 30 15:56:31 PST 2008


https://bugs.webkit.org/show_bug.cgi?id=22614





------- Comment #10 from jianli at chromium.org  2008-12-30 15:56 PDT -------
I've fixed most of things you pointed out. There are a couple more things I
need to get further feedback from you.

1) You asked me to remove "copyright to apple". What should I put there? Do I
just need to remove the copyright line and keep other comments intact?

2) As to calling ThreadSpecificThreadExit, I do not think making the cleanup
call from WTF thread is enough. This approach does not take care of the TLS
cleanup in the main thread and other threads not created by WTF::createThread.
I did not have a good solution here either. Which mailing list should I send to
for further discussion if needed?

I could only think of the following possible ways:

a) If we could make TLS allocations be self manageable, we do not need to deal
with this issue. That is, the caller is responsible to free the TLS allocation
when it is not longer needed.

b) Call ThreadSpecificThreadExit in each DllMain() when reason parameter is
DLL_THREAD_DETACH or DLL_PROCESS_DETACH.

c) If TLS data is only used in exe, not dll, we can use the hack as described
in 
 this article at http://www.codeproject.com/threads/tls.asp.


(In reply to comment #9)
> (In reply to comment #8)
> > The main issue here is that this basically changes JavaScriptCore API in an
> > objectionable way - I don't have a proposal, but this definitely needs to be
> > resolved.
> 
> Oh, in fact, nothing in JavaScriptCore uses ThreadSpecific, so I do have a
> proposal. I think that threads created with WTF::createThread() should just
> clean up when exiting - as it is done in Win32+pthreads case in
> wtfThreadEntryPoint (ThreadingWin.cpp).
> 


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list