[webkit-dev] pthreads and other threading primitives

[Darin Fisher]

On Mon, Sep 26, 2011 at 10:47 AM, Alexey Proskuryakov <ap at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110926/8030f3ca/attachment.html>