Re: [webkit-dev] [webkit-changes] [35474] trunk/JavaScriptCore

[Paul Pedriana]

I would hope that if any dependency is made on pthreads that the dependency be as minimal as possible and depend on the most universal parts of pthreads as possible. The platforms I work on do not have pthreads, and so pthreads would need to be emulated. Also, these platforms don't have some of the more esoteric features of pthreads (e.g. cancellation, signals, timed waits) in their native threading, and a dependency on such features could reduce portability. Actually, even under Windows we'd probably still use an emulated pthreads if possible instead of pthreads.dll, as the pthreads.dll for Windows does a lot of things that are typically not needed and increases the footprint more than we'd like (we are already running out of address space on Win32 in some of our own applications as it is).     >> But with pthreads, we get well tested implementations for many platforms I wonder if somebody has a list of platforms that pthreads exists for and is well-tested on. I'm not aware of it existing much outside of *nix, Mac, and Windows. I'm not saying this to argue against it, though I am wondering how common pthreads really is. Thanks. Paul 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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev