2022-07-19
Work Research
오늘은 반드시 WorkerDOM Scheduler를 잡아내자.
2022-07-11에 확인한 2가지 스케줄러를 확인한다.
Web Worker Thread에서 나타난 AnimationFrame.ts은 requestAnimationFrame에 관련된 것으로 보이고 Data Transfer과는 무관해보인다 (불확실).
즉 자세하게 봐야하는 것은 WorkerDOMConfiguration에 나온 다음 부분이다.
export interface WorkerDOMConfiguration {
// ...
// ---- Optional, with defaults
// Schedules mutation phase.
mutationPump: MutationPumpFunction
// ---- Optional Overrides
// Schedules long task.
longTask?: LongTaskFunction
// ...
}
LongTaskFunction의 차이는 Promise가 있다는 것이다.
MutationPumpFunction의 타입 정의는 다음과 같다.
export type MutationPumpFunction = (flush: Function, phase: Phase) => void
flush는 무언가 뒷정리를 하는 함수처럼 보인다 (불확실).
Phase는 다음과 같다.
export const enum Phase {
Initializing = 0,
Hydrating = 1,
Mutating = 2,
}
InboundWorkerDOMConfiguration과 WorkerDOMConfiguration의 차이는 무엇인가?
우선 다음과 같은 변환 함수가 있다.
InboundWorkerDOMConfiguration에는 없는 기본값을 설정해준다.
export function normalizeConfiguration(config: InboundWorkerDOMConfiguration): WorkerDOMConfiguration {
return Object.assign(
{},
{
mutationPump: requestAnimationFrame.bind(null),
executorsAllowed: DefaultAllowedMutations,
},
config
)
}
InboundWorkerDOMConfiguration 그리고 normalizeConfiguration이 Main Thread install.ts에만 사용되는 것으로 보아 최초 설치 시에만 InboundWorkerDOMConfiguration을 사용하는 것 같다.
도대체 어떤 방식으로 스케줄러가 동작하는지 아직 이해가 되지 않는다.
아예 스케줄러가 예상했던 동기적인 타이머가 있는 것이 아닌 것 같다 (불확실).
requestAnimationFrame에 의해 동작하는 것 같다 (불확실).
이 가정이 맞다면 requestAnimationFrame이 어떤 식으로 동작하는지 확인해야 한다.
Tim
Tim과 2시간 가량 이야기한 결과는 다음과 같다.
- (불확실)
- Web Worker Thread의
MutationTransfer.ts에transferSync레이어를 만든다. TransferrableKeys에 Sync 여부를 확인하는 키를 추가한다.- 동기적인 연산이 필요할 경우
- Web Worker Thread
transferSync에서 SAB를 하나 할당한다 TransferrableKeys를 통해 확인한다- Main Thread에서 Atomic Wait를 건다
- Main Thread의 해당 프로세서에서 작업을 처리한다
- 받은 SAB에 데이터를 채운다
- Web Worker Thread에 Atomic Notify를 한다
- Web Worker Thread
(불확실) Message 형식은 새로 만들어야 할 것 같고 Processor는 재활용할 수 있을 것 같다.