On Mon, Sep 26, 2011 at 1:47 PM, Alexey Proskuryakov <[email protected]> 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 > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > -- ................................................................ *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls <http://twitter.com/jarrednicholls>
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
