-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify and optimize worker task scheduling #10417
Changes from 6 commits
6560f92
457f808
92c4ca9
334c656
0651ec6
83d06d8
0cce742
e7aa5dc
32c29c5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,6 +4,7 @@ import {bindAll, isWorker, isSafari} from './util.js'; | |
import window from './window.js'; | ||
import {serialize, deserialize} from './web_worker_transfer.js'; | ||
import Scheduler from './scheduler.js'; | ||
import {PerformanceUtils} from './performance.js'; | ||
|
||
import type {Transferable} from '../types/transferable.js'; | ||
import type {Cancelable} from '../types/cancelable.js'; | ||
|
@@ -107,20 +108,22 @@ class Actor { | |
cancel.cancel(); | ||
} | ||
} else { | ||
if (isWorker() || data.mustQueue) { | ||
// In workers, store the tasks that we need to process before actually processing them. This | ||
// is necessary because we want to keep receiving messages, and in particular, | ||
// <cancel> messages. Some tasks may take a while in the worker thread, so before | ||
// executing the next task in our queue, postMessage preempts this and <cancel> | ||
// messages can be processed. We're using a MessageChannel object to get throttle the | ||
// process() flow to one at a time. | ||
if (isWorker() && data.mustQueue) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We need to pass the responses from getImages and getGlyphs to the scheduler. Checking for the presence of The queuing on the main thread was intentional but it looks like it might not be needed since we dropped IE. I think this is the only case where we did queuing on the main thread. It was also applied to iOS Safari < 12.1 but I don't think it was actually needed there... not sure though. @arindam1993 do you remember if the queuing was only needed for IE? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also old Safari verions wherein |
||
// for worker tasks that are often cancelled, such as loadTile, store them before actually | ||
// processing them. This is necessary because we want to keep receiving <cancel> messages. | ||
// Some tasks may take a while in the worker thread, so before executing the next task | ||
// in our queue, postMessage preempts this and <cancel> messages can be processed. | ||
// We're using a MessageChannel object to get throttle the process() flow to one at a time. | ||
const callback = this.callbacks[id]; | ||
const metadata = (callback && callback.metadata) || {type: "message"}; | ||
this.cancelCallbacks[id] = this.scheduler.add(() => this.processTask(id, data), metadata); | ||
} else { | ||
// In the main thread, process messages immediately so that other work does not slip in | ||
// between getting partial data back from workers. | ||
// Do the same for worker tasks that need processing as soon as possible. | ||
const m = isWorker() ? PerformanceUtils.beginMeasure('workerTask') : undefined; | ||
this.processTask(id, data); | ||
if (m) PerformanceUtils.endMeasure(m); | ||
} | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need to queue this on the main thread. We need to queue the response to this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, the intent was to make
mustQueue
force queing only on the worker thread, whether it's the task (if you're sending from the main) or the response (if you're sending from the worker).