Topics:[[BR]]

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

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.