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: ​http://trac.webkit.org/wiki/ThreadCommunication
  

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
  

Proposal (see link)

• 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):[[BR]]

• 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.