Press n or j to go to the next uncovered block, b, p or k for the previous block.
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 | 7x 4x 7x | /**
* Internal message interface between the worker and the master.
*
* None of this is public API.
*/
/* API documentation barrier. */
import { SchedulingFailure } from './api-types';
import { computeSchedule } from './scheduling';
// Ambient declarations.
//
// We do not rely on the TypeScript webworker library, because the current file is meant to be importable also by code
// that requires the DOM library. However, Web Worker API and DOM are at present mutually exclusive.
// https://github.com/Microsoft/TypeScript/issues/20595
// Since the Web Worker API used in this file is extremely simple, we just make the declarations ourselves here.
declare global {
/**
* A web worker’s global scope.
*/
interface DedicatedWorkerGlobalScope {
/**
* EventHandler to be called when a message is sent to the worker using its `postMessage()` method.
*/
onmessage: ((this: DedicatedWorkerGlobalScope, event: MessageEvent) => any) | null;
/**
* Sends a message to the main thread that spawned the worker.
*
* The web worker API specifies an optional second argument for postMessage(), which we do not use. Unfortunately,
* information on the web is not crystal clear on whether it should be possible to transfer (without copying) a
* plain JavaScript object from the worker to the thread that spawned it. In C++ terminology, this would be called
* move semantics.
*
* See for instance a discussion on
* [StackOverflow](https://stackoverflow.com/questions/33544994/pass-object-by-reference-from-to-webworker) or a
* related
* [issue of the TypeScript project on GitHub]
* (https://github.com/Microsoft/TypeScript/issues/25176#issuecomment-400117198).
*
* For now the answer is, however, very clear. It is not possible. Chrome 74 reports "Value at index 0 does not have
* a transferable type" if we were to set the `transfer` argument in the postMessage() invocation to `[plainObject]`
* (i.e., an array with a plain JavaScript object as only element).
*/
postMessage(message: any): void;
/**
* Closes the worker from inside the worker itself.
*/
close(): void;
}
/**
* The DedicatedWorkerGlobalScope constructor.
*/
// tslint:disable-next-line:variable-name
let DedicatedWorkerGlobalScope: new() => DedicatedWorkerGlobalScope;
}
/**
* Type guard that returns whether the given value is a {@link DedicatedWorkerGlobalScope}.
*/
export function isDedicatedWorkerGlobalScope(value: any): value is DedicatedWorkerGlobalScope {
return typeof DedicatedWorkerGlobalScope === 'function' && value instanceof DedicatedWorkerGlobalScope;
}
// Internal interfaces
/**
* Message from master to worker with all information to start processing.
*/
export type ComputeScheduleParameters = Parameters<typeof computeSchedule>;
/**
* Message from worker to master containing the result.
*/
export type ComputeScheduleReturnType = ReturnType<typeof computeSchedule>;
/**
* Factory for a web worker.
*
* The {@link Worker} constructor requires a script URL that is either absolute or relative *to the the domain* of the
* current script. See: https://html.spec.whatwg.org/multipage/workers.html#dom-worker
*
* Unfortunately, the location of the current script is generally unknowable. Additionally, in case of the UMD
* distribution of this module, the worker script is the simply the current script (for ease of distribution).
* Otherwise, the worker script is in a separate file, and we expect a bundler to substitute the correct absolute URL at
* build time.
*/
export interface WorkerFactory {
/**
* Creates and returns a new {@link Worker}, or a failure if an error occurs.
*/
createWorker?: () => Worker | SchedulingFailure;
}
export const workerFactory: WorkerFactory = {};
|