220719

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를 한다

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

Personal Research

• Autosave Everything
• Developing Review Notes for Obsidian