| 12 | | * Moving to a dispatch type model (thread pool, etc.) -- proposal (ap?, jchaffix?).[[BR]] |
| | 14 | WebWorkers (david_levin):[[BR]] |
| | 15 | * Mostly uses queue of tasks to pass messages between threads[[BR]] |
| | 16 | * Also some template magic to do the boiler plate code for message handling[[BR]] |
| | 17 | |
| | 18 | Compositor[[BR]] |
| | 19 | * Another good pattern[[BR]] |
| | 20 | * Very specific to this code[[BR]] |
| | 21 | * Have to do a lot of explicit copies of some data structure (String...)[[BR]] |
| | 22 | * Common data structure are not designed to be shared (mainly String agian)[[BR]] |
| | 23 | |
| | 24 | Audio API[[BR]] |
| | 25 | * They share the nodes between threads[[BR]] |
| | 26 | * Had had to create a new sharing model[[BR]] |
| | 27 | * The high priority audio thread is the one destroying the nodes[[BR]] |
| | 28 | * Not sure it should be generalized as it uses background threads' priority to solve some of the lifetime issues[[BR]] |
| | 29 | |
| | 30 | Current situation:[[BR]] |
| | 31 | * Sharing is bad as most objects are not designed to be shared[[BR]] |
| | 32 | * Strings for example are not shareable through threads (for performance)[[BR]] |
| | 33 | * Locking also is difficult to get right[[BR]] |
| | 34 | * Keep things isolated between threads![[BR]] |
| | 35 | * Don't do sharing! Difficult bugs too![[BR]] |
| | 36 | * Lots of copies involved to avoid sharing![[BR]] |
| | 37 | * Currently to be called back on the main thread, we use a Timer that is expensive and we need to keep some state.[[BR]] |
| | 38 | * Some dispatching API for running a task on this specific thread[[BR]] |
| | 39 | * XHR, File, IconDB all go back to the main thread[[BR]] |
| | 40 | * SQLDB has either to handle mainThread or another thread.[[BR]] |
| | 41 | * Ping-ponging easy to get wrong, you would need some object to handle that![[BR]] |
| | 42 | * Example is the DB where you don't need to send a CleanUp task when the thread is dead.[[BR]] |
| | 43 | |
| | 44 | * Future patterns: http://trac.webkit.org/wiki/ThreadCommunication [[BR]] |
| | 45 | |
| | 46 | Why not a templated cross-shared String?[[BR]] |
| | 47 | * Problem with performance![[BR]] |
| | 48 | * There is some mitigation already (semi efficient implementation for long String that avoid copying)[[BR]] |
| | 49 | |
| | 50 | Why not develop a push API for GraphicsContext?[[BR]] |
| | 51 | |
| | 52 | Issues[[BR]] |
| | 53 | * WebWorker complex because the lifetimes of both thread are independent[[BR]] |
| | 54 | |
| | 55 | Proposal (see link)[[BR]] |
| | 56 | * Template magic to match the API (like this is a String or something else)[[BR]] |
| | 57 | * Currently using raw pointers so we will need to Decorate them[[BR]] |
| | 58 | * Lifetime to be determined by the 'originated' thread[[BR]] |
| | 59 | * At some point, share code of Tasks, MessageQueues... in a common implementation somehow[[BR]] |
| | 60 | |
| | 61 | |
| | 62 | * Moving to a dispatch type model (thread pool, etc.) -- proposal (ap?, jchaffraix?).[[BR]] |
| | 63 | |
| | 64 | Somebody (sorry I did not take his name) called this: SystemWorldThread[[BR]] |
| | 65 | * Some threading cannot be moved to that (Audio...)[[BR]] |
| | 66 | * Some problem with some models[[BR]] |
| | 67 | * Maybe need some models[[BR]] |
| | 68 | * Game engines push the Audio to its own thread, the rest uses ThreadPools[[BR]] |
| | 69 | * Maybe not a size-fits-all solutions[[BR]] |
| | 70 | * Lots of values in having common Task[[BR]] |
| | 71 | * jchaffraix needs to sync with Ap about an API for that.[[BR]] |
| | 72 | |
| | 73 | Current work (https://bugs.webkit.org/show_bug.cgi?id=43903):[[BR]] |
| | 74 | * Parallelize SVG filters[[BR]] |
| | 75 | * Nice performance improvements[[BR]] |
| | 76 | * Also implemented a first API inspired by OpenMP[[BR]] |
| | 77 | * However there are others libraries / API available for multi-threading[[BR]] |
