wiki:April 2011 Meeting/Threading

Version 7 (modified by jchaffraix@webkit.org, 13 years ago) (diff)

Fixed the section to make it more obvious what were the topics

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

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 agian)

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[[BR]]
  • Don't do sharing! Difficult bugs too[[BR]]
  • Lots of copies involved to avoid sharing[[BR]]
  • 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[[BR]]
  • 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[[BR]]
  • There is some mitigation already (semi efficient implementation for long String that avoid copying)

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.