On Jun 9, 2005, at 1:35 PM, Justin Haygood wrote:
I want to know pretty much what the reason behind each of these are, so I can better implement it using another also portable threading library (NSPR):
markCurrentThreadConservatively() markOtherThreadConservatively(Thread *thread)
What does mark conversatively mean? NSPR doesn't have a way to access the stack objects of each thread, so I'm in a bit of a bind. The NSPR threading library does have pretty much everything else a threading library needs, and is very clean.
Hi Justin, Besides Darin's comments, I'll add the following: All you really need to get a JavaScriptCore that works with WebCore is markCurrentThreadConservatively(). All the logic for marking other threads could be left out. The reason is that WebCore uses JavaScriptCore in a completely single-threaded way. The reason we take care of marking objects pointed to from other threads is that on Mac OS X, other pieces of the system use JavaScriptCore, sometimes in a multithreaded way. In fact, CFNetwork, the http loader library we use way down under the covers, uses it to parse PAC files on background threads. So we need the collector to be threadsafe. But this should not be needed if you only want to use JavaScriptCore from WebCore. So, you could probably #ifdef out all the support for marking other threads. I believe the one non-portable construct you will need to find a way to do is how to get the stack base of the main thread (or alternately the currently running thread, both should be the same). I know that on other platforms such as Linux there is a direct call to do this that doesn't involve the threading library. I'm not sure about the situation on Windows. Regards, Maciej P.S. I see that you've been doing a lot of work to get stuff building and working on Windows. I think it would be great to start getting your changes in incrementally. Please send patches for the individual issues you've addressed to webkit-changes whenever ready (or point to a bug report if you put them in bugzilla).