Changes between Version 3 and Version 4 of ThreadCommunication


Ignore:
Timestamp:
Apr 14, 2011 10:20:03 AM (9 years ago)
Author:
levin@chromium.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ThreadCommunication

    v3 v4  
    1212'''Use cases'''
    1313
    14 1. 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.
    15 This one is a superset of other potential cases including fire and forget.[[BR]]
     141. An object exist on one thread. It wants to create an object on another thread and be able to call methods on it.
     15This is a superset of other potential cases including fire and forget.[[BR]]
    1616
     172. An object wants to be able to allow another thread to be able to call its methods.[[BR]]
    1718
    18 Issue: Should this use case be broken up into several?[[BR]]
     193. A function wants to call a method on another thread and wait until it is done. Allowing callbacks resulting from that to run in the web worker thread.
     20This 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]]
    1921
    20 
    21 2. 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.
    22 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.[[BR]]
     22The framework should track the dependencies to check for possible deadlocks.[[BR]]
    2323
    2424
     
    3434'''Proposed code samples for use cases'''
    3535
    36 TBD: Here is where some code will go to show what these use cases look like.
     36Case 1: Create an object on another thread:[[BR]]
     37
     38{{{
     39    // Creates a proxy and initializes a target object on a given message loop.
     40    RefPtr<TypeName::Proxy> proxy = TypeName::createProxy(otherMessageLoop, constructorArg1, constructorArg2, ...);
     41
     42    // Calls method on the object on the other message loop. This does not need to wait for some signal that the object has been created.
     43    proxy->invoke(&TypeName::method, arg1, arg2, ...);
     44}}}
     45
     46Case 2: Allow an object on another thread to do callbacks:[[BR]]
     47
     48{{{
     49    // getProxy is a method in the current object which returns its proxy. The proxy may be used with invoke like these examples.
     50    proxy->invoke(&TypeName::method, arg1, getProxy(), arg3, ...);
     51}}}
    3752
    3853
     54Case 3: A thread wants to call a function on another thread and wait until it is done.
     55
     56TBD