메인 내용으로 이동

2022-07-19

Work Research

오늘은 반드시 WorkerDOM Scheduler를 잡아내자. 2022-07-11에 확인한 2가지 스케줄러를 확인한다. Web Worker Thread에서 나타난 AnimationFrame.tsrequestAnimationFrame에 관련된 것으로 보이고 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,
}

InboundWorkerDOMConfigurationWorkerDOMConfiguration의 차이는 무엇인가? 우선 다음과 같은 변환 함수가 있다. 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.tstransferSync 레이어를 만든다.
  • TransferrableKeys에 Sync 여부를 확인하는 키를 추가한다.
  • 동기적인 연산이 필요할 경우
    • Web Worker Thread transferSync에서 SAB를 하나 할당한다
    • TransferrableKeys를 통해 확인한다
    • Main Thread에서 Atomic Wait를 건다
    • Main Thread의 해당 프로세서에서 작업을 처리한다
    • 받은 SAB에 데이터를 채운다
    • Web Worker Thread에 Atomic Notify를 한다

(불확실) Message 형식은 새로 만들어야 할 것 같고 Processor는 재활용할 수 있을 것 같다.

Personal Research