[webkit-dev] pthreads and other threading primitives
In the wake of Geoff's work to simplify threading ifdefs, and Adam's review of supported ports, I'm curious what people think about maintaining many platform branches in our WTF and JavaScriptCore threading code. Right now, it feels rather non-systemic, with some code built upon pthreads, Qt or Gtk libraries, and some calling into Win32 API directly. Some specific examples: - JavaScriptCore/heap/MachineStackMarker.h only works with pthreads; - FastMalloc works with pthreads or Win32 API; - ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API; - code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely custom. Chromium doesn't even use supposedly cross-platform parts in MainThread.cpp. Supporting multiple implementation has a high cost, both in the work directly applied to that, and in having subtle behavior differences. Checking svn blame for ThreadingQt.cpp and ThreadingGtk.cpp for example, I see that most lines are last touched by people who are not directly affiliated with these ports. I remember that performance was given as the primary reason to not use pthreads everywhere. What pthreads functionality in particular needs to be reimplemented in WTF for performance? And are there big reasons to use anything except for POSIX and Win32 APIs for us? Do we want to require that platforms support pthreads, so that code that isn't performance critical could have just one implementation? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] pthreads and other threading primitives
On Mon, Sep 26, 2011 at 1:47 PM, Alexey Proskuryakov a...@webkit.org wrote: In the wake of Geoff's work to simplify threading ifdefs, and Adam's review of supported ports, I'm curious what people think about maintaining many platform branches in our WTF and JavaScriptCore threading code. Right now, it feels rather non-systemic, with some code built upon pthreads, Qt or Gtk libraries, and some calling into Win32 API directly. Some specific examples: - JavaScriptCore/heap/MachineStackMarker.h only works with pthreads; - FastMalloc works with pthreads or Win32 API; - ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API; - code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely custom. Chromium doesn't even use supposedly cross-platform parts in MainThread.cpp. Supporting multiple implementation has a high cost, both in the work directly applied to that, and in having subtle behavior differences. Checking svn blame for ThreadingQt.cpp and ThreadingGtk.cpp for example, I see that most lines are last touched by people who are not directly affiliated with these ports. I remember that performance was given as the primary reason to not use pthreads everywhere. What pthreads functionality in particular needs to be reimplemented in WTF for performance? And are there big reasons to use anything except for POSIX and Win32 APIs for us? IMHO, I think JSC should go right to the metal rather than be abstracted with port specific threading classes. In other words, it should be broken out by platform threading libs - POSIX and Win32 - and not by port. After a very rudimentary scan, I saw no reason to not use straight Win32 and POSIX. This would arguably reduce port barrier-to-entry and maintenance, on top of the obvious code simplicity and slight performance increase. Do we want to require that platforms support pthreads, so that code that isn't performance critical could have just one implementation? That's the status quo :) MachineStackMarker only works with pthreads, so QtWin32 and Win ports need pthreads-win32 right now. pthreads is the least common denominator at the moment. Though there are performance reasons for getting away from that, there is also the fact that pthreads-win32 is an unmaintained project whose last update was 5 years ago. - WBR, Alexey Proskuryakov Definitely worth a full reviewer analysis and vote I think. This is one of the many WebKit cleanup tasks to consider. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] pthreads and other threading primitives
On Mon, Sep 26, 2011 at 10:47 AM, Alexey Proskuryakov a...@webkit.org wrote: In the wake of Geoff's work to simplify threading ifdefs, and Adam's review of supported ports, I'm curious what people think about maintaining many platform branches in our WTF and JavaScriptCore threading code. Right now, it feels rather non-systemic, with some code built upon pthreads, Qt or Gtk libraries, and some calling into Win32 API directly. Some specific examples: - JavaScriptCore/heap/MachineStackMarker.h only works with pthreads; - FastMalloc works with pthreads or Win32 API; - ThreadSpecific uses pthreads, Qt, Gtk, or Win32 API; - code in various ThreadingXXX.cpp and MainThreadXXX.cpp files is entirely custom. Chromium doesn't even use supposedly cross-platform parts in MainThread.cpp. This was done to avoid the queue that callOnMainThread creates. It causes both subtle bugs and performance problems for Chromium. Our native MessageLoop can implement MainThread.h directly and without those issues, so it makes sense for us to just use our port's primitives. However, I realize this approach was not free of trouble. Recently, someone added cancelCallOnMainThread, which cannot be implemented easily on top of the Chromium MessageLoop. Fortunately, that method is not called by any code that the Chromium port compiles, but unfortunately, it is a bit of a ticking-timebomb. Someone will invariably try to use it and then be frustrated that Chromium doesn't support it. I think that it is a poor API because it requires searching the work queue, so I would prefer to remove cancelCallOnMainThread or redesign it so it can be implemented efficiently. -Darin Supporting multiple implementation has a high cost, both in the work directly applied to that, and in having subtle behavior differences. Checking svn blame for ThreadingQt.cpp and ThreadingGtk.cpp for example, I see that most lines are last touched by people who are not directly affiliated with these ports. I remember that performance was given as the primary reason to not use pthreads everywhere. What pthreads functionality in particular needs to be reimplemented in WTF for performance? And are there big reasons to use anything except for POSIX and Win32 APIs for us? Do we want to require that platforms support pthreads, so that code that isn't performance critical could have just one implementation? - 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
Re: [webkit-dev] pthreads and other threading primitives
On Mon, 26 Sep 2011 14:08:41 -0400, Jarred Nicholls wrote: Do we want to require that platforms support pthreads, so that code that isn't performance critical could have just one implementation? That's the status quo :) MachineStackMarker only works with pthreads, so QtWin32 and Win ports need pthreads-win32 right now. pthreads is the least common denominator at the moment. Though there are performance reasons for getting away from that, there is also the fact that pthreads-win32 is an unmaintained project whose last update was 5 years ago. Since this thread started with bug 54836, I want to add that this is the main reason for the red WinCE buildbot. There is no official working pthread library for WinCE (at least for ARM) and it's not an easy task to get it working. So I prefer at least POSIX and Win32 API for threading stuff. - Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] pthreads and other threading primitives
Do we want to require that platforms support pthreads, so that code that isn't performance critical could have just one implementation? It might work to require either POSIX threads or Win32 threads in all build configurations, and refactor or remove other threading code. It's a bit weird to require POSIX threads on Windows, since, as Jarred points out, the implementation isn't really maintained. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
