[Webkit-unassigned] [Bug 92365] Refactor cross thread communication

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=92365





--- Comment #4 from David Levin <levin at chromium.org>  2012-07-27 00:26:30 PST ---
(In reply to comment #3)

> There are some cases canceling a group of the tasks.
> AsyncFileStream::stop() method unschedules all tasks related to specific FileStream instance by calling FileThread::unscheduleTasks() method. DatabaseThread also has an API for unscheduling all tasks related to specific Database instance.
> 

Ok. I misread thing before anyway. I kind of like the TaskGroup thing but I wonder why:
1. I can't just call cancel on it.
2. Why it is called TaskGroup when its sole purpose is to be able to cancel tasks?
3. If there is some error check to determine if it is passed to more than one TaskThread (or perhaps that is ok).



> But I have to keep the behavior of WTF::Function. For some types like WTF::String, because of that, parameters are copied manually using deepCopy() function.
> 

Only refer counting the first item seems odd and error prone. I'm all for getting rid of CrossThreadTask but I don't think that WTF::Function plays the same role with this odd behavior. (Actually, I think the CrossThreadTask isn't bad but ScriptExecutionContext should be removed from it.) If WTF::Function is used like CrossThreadTask, then perhaps it should get the functionality to copy/ref every parameter instead of just the first (and CrossThreadTask can go away).


One more comment re TaskThread, instead of making it ThreadSafeRefCounted, I'd suggest make a TaskThreadProxy that other threads could use. (The Proxy would hold some sort of weak pointer to a TaskThread.) From what I've seen typically it is nice for a run loop to know which thread it will be destroyed on.


btw, thanks for taking this up. I didn't have time to complete all of this and more recently my time on WebKit, etc. has been vastly reduced (largely to making comment like this :).), so I'll admit that perhaps my views may be out of touch with any new thinking that has happened.

btw, https://trac.webkit.org/wiki/ThreadCommunication was meant to be the highest level of abstraction with lower level things that could be used. But perhaps it is ok just to go for this lower level but there were some common error prone patterns that kept emerging which insipred it.


PS I think this " void postImmediateTask(PassOwnPtr<TaskThreadTask> task);" is a typo (i.e. TaskThreadTask).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.