On Jul 31, 2008, at 11:40 PM, Justin Haygood wrote:
Well, what I'm saying is that maintaining our own abstraction layer is a large and unnecessary burden.
We already do maintain it... WebCore uses it quite heavily. Why not use it?
Right now, the abstraction is weaker than needed by JSC, and hasn't been scrutinized for interoperability in non-trivial cases (e.g. WebCore threads never die, so we didn't need to define and interoperably implement the behavior of synchronization primitives in this case). Obviously, the suggestion to more fully embrace pthreads involves removing other implementations from Threading*.cpp eventually, so that we wouldn't need to maintain this code.
It uses the platform's native threading APIs (gthread on glib, QThread on Qt, pthread on OS X, Win32 threads on Win32)
Naturally, pthreads also uses native threading APIs on each platform (even more native, as it does not go through Qt/gtk wrappers, which may become important for performance and correctness). But with pthreads, we get well tested implementations for many platforms, with an API that is documented in man pages, books etc. Are there any benefits in redoing all this work? As Brent wrote, not having to include pthreads.dll is beneficial, but I do not see why one couldn't statically link pthreads, if needed. - WBR, Alexey Proskuryakov