[webkit-dev] pthreads and other threading primitives
Alexey Proskuryakov
ap at webkit.org
Mon Sep 26 10:47:40 PDT 2011
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
More information about the webkit-dev
mailing list