make it possible to enable USE(MULTIPLE_THREADS) on other platforms

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Darin Fisher (:fishd, Google)]

make it possible to enable USE(MULTIPLE_THREADS) on other platforms

Currently, it is trivial to provide a platform-specific JSLock.cpp file and to specify the macros that dtoa.cpp requires when USE(MULTIPLE_THREADS) is specified.  However, collector.cpp needs some modifications to make it portable.

Patch coming up...

[Darin Fisher (:fishd, Google)]

Created attachment 13672 [details]
patch

[Darin Fisher (:fishd, Google)]

Created attachment 13674 [details]
patch: make isMainThread be a static member function

ap pointed out that it would ease porting if isMainThread were a static member function.

[Alexey Proskuryakov]

(In reply to comment #2)
> ap pointed out that it would ease porting if isMainThread were a static member
> function.

Actually, I just asked how this patch makes it possible to enable USE(MULTIPLE_THREADS) on other platforms if it doesn't implement isMainThread() for those. Morgan's answer was that it can be specified using -D.

[Darin Fisher (:fishd, Google)]

True, true... anyways, after we discussed that, I decided that it would be better to specify it as a static member function.  That seems more consistent with how other code in webkit is made portable.

[Darin Adler]

Comment on attachment 13674 [details]
patch: make isMainThread be a static member function

This function is quite performance-critical. Thus I'd prefer that the Darwin versino of the function be marked inline.

+  return pthread_main_np() == 1;

That's incorrect. != 0 would be correct.

review- before of the incorrect call for pthread_main_np()

[Darin Adler]

because of

[Darin Fisher (:fishd, Google)]

> This function is quite performance-critical. Thus I'd prefer that the Darwin
> versino of the function be marked inline.

Oh, does the Mac generate relocation entries for static class functions?  I know that ELF (Linux) does so, which really sucks.  On Windows, such a static class member function would just be entirely optimized away.  Is that really not the case on Mac?


> +  return pthread_main_np() == 1;
> 
> That's incorrect. != 0 would be correct.

OK.  I read some documentation that claimed that -1 indicated an error, 0 indicated false, and 1 indicated true.  I agree that != 0 matches existing usage, so that does seem better.

[Darin Fisher (:fishd, Google)]

Created attachment 13714 [details]
patch: make inline and compare against 0

revised as requested

[Darin Adler]

Comment on attachment 13714 [details]
patch: make inline and compare against 0

r=me

[Maciej Stachowiak]

I don't think this should be landed, since it conflicts with my patch that will make this one unnecessary. Changing to r-. Discussed with submitter.

[Maciej Stachowiak]

I fixed this in a different way.