wiki:April 2011 Meeting/Threading

Version 9 (modified by levin@chromium.org, 9 years ago) (diff)

--

Topics:

Common pitfalls

Current patterns

Those are the areas where we have some threading:

  • WebWorkers
  • FileAPI
  • Database (IconDatabase)
  • Compositor (Chromium specific)
  • Audio API

WebWorkers (david_levin):

  • Mostly uses queue of tasks to pass messages between threads
  • Also some template magic to do the boiler plate code for message handling

Chromium compositor

  • Another good pattern
  • Very specific to this code
  • Have to do a lot of explicit copies of some data structure (String...)
  • Common data structure are not designed to be shared (mainly String again)

Audio API

  • They share the nodes between threads
  • Had had to create a new sharing model
  • The high priority audio thread is the one destroying the nodes
  • Not sure it should be generalized as it uses background threads' priority to solve some of the lifetime issues

Current situation:

  • Sharing is bad as most objects are not designed to be shared
  • Strings for example are not shareable through threads (for performance)
  • Locking also is difficult to get right
  • Keep things isolated between threads!
  • Don't do sharing! Difficult bugs too!
  • Lots of copies involved to avoid sharing!
  • Currently to be called back on the main thread, we use a Timer that is expensive and we need to keep some state.
  • Some dispatching API for running a task on this specific thread
  • XHR, File, IconDB all go back to the main thread
  • SQLDB has either to handle mainThread or another thread.
  • Ping-ponging easy to get wrong, you would need some object to handle that!
  • Example is the DB where you don't need to send a CleanUp task when the thread is dead.

Future patterns

Why not a templated cross-shared String?

  • Problem with performance!
  • There is some mitigation already (semi efficient implementation for long String that avoid copying) -- (gbarra pointed out afterwards that this is broken at the moment. It was broken by the change to allocate the string buffer in one chunk with the StringImpl. He has some good ideas about how to fix this.)

Why not develop a push API for GraphicsContext?

Issues

  • WebWorker complex because the lifetimes of both thread are independent

ThreadCommunication proposal (see http://trac.webkit.org/wiki/ThreadCommunication)

  • Template magic to match the API (like this is a String or something else)
  • Currently using raw pointers so we will need to Decorate them
  • Lifetime to be determined by the 'originated' thread
  • At some point, share code of Tasks, MessageQueues... in a common implementation somehow

Moving to a dispatch type model (thread pool, etc.) -- proposal (ap?, jchaffraix?)

Somebody (sorry I did not take his name) called this: SystemWorldThread

  • Some threading cannot be moved to that (Audio...)
  • Some problem with some models
  • Maybe need some models
  • Game engines push the Audio to its own thread, the rest uses ThreadPools
  • Maybe not a size-fits-all solutions
  • Lots of values in having common Task
  • jchaffraix needs to sync with Ap about an API for that.

Current work (https://bugs.webkit.org/show_bug.cgi?id=43903):

  • Parallelize SVG filters
  • Nice performance improvements
  • Also implemented a first API inspired by OpenMP
  • However there are others libraries / API available for multi-threading

What to parallelize

Not treated.