Migrate Async Clipboard to use updated task types and functions |
||||
Issue descriptionAsync Clipboard code in clipboard_promises.cc currently uses code that could restrict paralellism. - Thread affinity isn't required, so update SingleThreadedTaskRunner references to SequenceTaskRunner. - Use CrossThreadBind to specify that we hope to go CrossThread, and are okay with a function/task being called/destructed on another thread. References: https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/wtf/functional.h?gsn=CrossThreadClosure&l=62 : // WTF::Bind(), WTF::BindRepeating and base::{Once,Repeating}Callback should // be used for same-thread closures only, i.e. the closures must be created, // executed and destructed on the same thread. // Use crossThreadBind() and CrossThreadClosure if the function/task is called // or destructed on a (potentially) different thread from the current thread. https://cs.chromium.org/chromium/src/base/single_thread_task_runner.h?type=cs&q=singlethreadtaskrunner&sq=package:chromium&g=0&l=15 // A SingleThreadTaskRunner is a SequencedTaskRunner with one more // guarantee; namely, that all tasks are run on a single dedicated // thread. Most use cases require only a SequencedTaskRunner, unless // there is a specific need to run tasks on only a single thread.
,
Dec 18
,
Dec 19
As noted by dcheng in crrev.com/c/1382865: "ClipboardPromise is an Oilpan object, and every Oilpan object has thread-affinity. While it is possible to use Oilpan objects cross-thread, there is some overhead in doing so, as everything needs to become a cross thread persistent."
,
Dec 19
As thread affinity is in fact required, this bug is not valid, and I'll close it.
,
Dec 19
For further explanation on why oilpan objects are thread-affine: " From https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/heap/BlinkGCDesign.md "Each thread is responsible for destructing objects that the thread has allocated. That way objects are guaranteed to get destructed on the thread that has allocated the objects." It seems all Oilpan objects are thread-affine because they can only get destructed on the thread that allocated them. It is still possible to use cross-thread pointers w/CrossThreadPersistent though, as mentioned in this doc. However, doing so requires a "global lock", which I guess part of the overhead you referenced. " |
||||
►
Sign in to add a comment |
||||
Comment 1 by huangdarwin@chromium.org
, Dec 18