Changes between Version 7 and Version 8 of April 2011 Meeting/Threading


Ignore:
Timestamp:
Apr 27, 2011 2:19:43 PM (13 years ago)
Author:
jchaffraix@webkit.org
Comment:

Added a better formatting (s/

Legend:

Unmodified
Added
Removed
Modified
  • April 2011 Meeting/Threading

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