Changes between Version 2 and Version 3 of ThreadCommunication


Ignore:
Timestamp:
Apr 12, 2011 3:56:55 PM (9 years ago)
Author:
levin@chromium.org
Comment:

Formatting changes.

Legend:

Unmodified
Added
Removed
Modified
  • ThreadCommunication

    v2 v3  
    11'''Introduction'''
    22
    3 There are multiple places in WebKit where we do communication between threads. Each of these has a slightly different model, but all are pretty similar. The problems we have with our current scheme are:
    4 1. Every time someone need to do this, they need to write their own version of it, which leads to many typical problems with duplicate code.
    5 2. Common operations are need to be hand written each time requiring careful review of tricky lifetime code which is easy to get wrong.
     3There are multiple places in WebKit where we do communication between threads. Each of these has a slightly different model, but all are pretty similar. The problems we have with our current scheme are:[[BR]]
     4
     51. Every time someone need to do this, they need to write their own version of it, which leads to many typical problems with duplicate code.[[BR]]
     6
     72. Common operations are need to be hand written each time requiring careful review of tricky lifetime code which is easy to get wrong.[[BR]]
     8
    69
    710To fix these, it would be good to have some common data structures/api which handle common operations without requiring much boilerplate code. Let's start by enumerating out common cases.
     
    1013
    11141. An object exist on one thread. It wants to create an object on another thread and then have a number of calls happen between these two objects.
    12 This one is a superset of other potential cases including fire and forget.
     15This one is a superset of other potential cases including fire and forget.[[BR]]
    1316
    14 Issue: Should this use case be broken up into several?
     17
     18Issue: Should this use case be broken up into several?[[BR]]
     19
    1520
    16212. A web worker thread wants to call a function on another thread and wait until it is done. Allowing callbacks resulting from that to run in the web worker thread.
    17 This does look suspiciously like a nested message loop with a filter which many people regard as evil. The only reason to allow this capability is for synchronous calls from javascript to call to the main thread to get some work done and act like a synchronous call but there may be callbacks (e.g. when doing a sync xhr call.) Theoretically, the javascript engine could roll up its state into a closure and we could avoid the nested message loop but that capability doesn't exist in the engines that we deal with and would be very expensive to add to them.
     22This does look suspiciously like a nested message loop with a filter which many people regard as evil. The only reason to allow this capability is for synchronous calls from javascript to call to the main thread to get some work done and act like a synchronous call but there may be callbacks (e.g. when doing a sync xhr call.) Theoretically, the javascript engine could roll up its state into a closure and we could avoid the nested message loop but that capability doesn't exist in the engines that we deal with and would be very expensive to add to them.[[BR]]
    1823
    19 Constraints:
    20 The api should be simple to use and handle things like ensuring objects are appropriately copied or ref counted and make it easier to deal with lifetime issues.
    2124
    22 Either object should be able to be deleted at any time and the other side shouldn't cause any memory corruption issues by sending more messages.
     25''Constraints:''[[BR]]
    2326
    24 Allow for a thread pool scenario. (This isn't about implementing the thread pool but ensuring that the implementation suggested doesn't preclude one being done in the future).
     27* The api should be simple to use and handle things like ensuring objects are appropriately copied or ref counted and make it easier to deal with lifetime issues.[[BR]]
     28* Either object should be able to be deleted at any time and the other side shouldn't cause any memory corruption issues by sending more messages.[[BR]]
     29* Allow for a thread pool scenario. (This isn't about implementing the thread pool but ensuring that the implementation suggested doesn't preclude one being done in the future).[[BR]]
     30
    2531
    2632TBD: There are likely more use cases to be listed here.