[220201] Node.js EventLoop

event loop는 Node.js가 가능한 경우 시스템 커널에 작업을 떠넘겨서(offloading) non-blocking I/O operation을 수행하게 해준다. (Javascript가 single-threaded 임에도)

모던 커널들은 대부분 멀티스레드를 지원하기 때문에, 이들은 백그라운드에서 여러 작업을 처리할 수 있다. 이러한 작업 중 하나가 완료되면 커널은 Node.js에 알려준다. 그러면 Node.js는 적절한 콜백이 poll 큐에 추가되어 종내에는 이 콜백이 실행된다.

Node.js 가 시작하면

1. processes the provided input script (or drops into the REPL) which may make async API calls 비동기 API호출을 만들어내는 (제공되는) 입력 스크립트 수행
2. 타이머 스케줄링
3. 혹은 process.nextTick() 호출
4. 이제 이벤트 루프를 프로세스를 시작한다.

아래 다이어그램은 이벤트 루프의 작동 순서를 간략하개 보여준다.

   ┌───────────────────────────┐
┌─>│           timers          │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │
   └───────────────────────────┘

각 상자는 이벤트 루프의 페이즈(phase)로 불린다.

각 페이즈에는 실행할 콜백들의 FIFO 큐(대기열)가 있다. 각 단계는 그 나름대로 특별하지만, 일반적으로 이벤트 루프가 주어진 페이즈에 들어갈 때, 해당 페이즈에 특화된 모든 연산들을 수행한 다음, (해당 페이즈의) 큐 안에 콜백들을 수행한다. (모두 소진되거나 최대 수의 콜백이 실행될 때까지) 큐가 소진되거나 콜백 제한에 도달하면 이벤트 루프가 다음 페이즈로 이동한다.

이러한 작업들 중 하나가 더 많은 작업(operation)을 예약할 수 있고(schedule), poll 페이즈에서 처리된 새로운 이벤트가 커널에 의해 대기열(큐)에 있을 수 있으므로, poll 이벤트

이러한 작업들 중 하나가 더 많은 작업을 예약할 수도 있고, 폴링 단계에서 처리된 새 이벤트가 커널에 의해 대기열에 있으므로 폴링 이벤트가 처리되는 동안 poll 이벤트들은 대기열(queue)에 추가될 수 있다. (뭐… 작업 중에도 이벤트는 들어올 수 있다라는 말인듯)

결과적으로 콜백이 오래 실행되면 poll 페이즈가 타이머임계값(timer's threshold)보다 오래 실행될 수 있다. 자세한 내용은 아래 timer섹션과 poll섹션을 참고하자.

Windows과 Unix/Linux 구현체 사이에 약간의 차이(discrepancy)가 있지만 여기서는 중요하지 않다. 실제로 7~8단계가 있지만 우리가 중요하게 여겨야할 (실제로 사용하는) 단계는 위에 있는 단계이다.

• timers : 이 페이즈는 setTimeout() , setInterval() 로 예약된 콜백을 실행한다.
• pending callbacks : 다음 루프까지 지연된 I/O 콜백을 실행한다.
• idle, prepare : 내부적으로만 사용됨.
• poll : 새로운 I/O 이벤트를 조회한다; I/O 관련 콜백 실행 (타이머에 의해 예약된 콜백 및 setImmediate() 을 제외한 거의 모든 것. (node will block here when appropriate, 차단해야하는 경우 차단함. 너무 길어지거나 하면 그만하도록 시킴)
• check : setImmediate() 콜백들은 여기서 호출됨.
• close callbacks : 일부 close callbacks 수행 (예 socket.on('close', ...) )

각 이벤트 루프 실행 사이에 Node.js는 비동기 I/O 또는 timers 를 기다리고 있는지 확인하고 아무 것도 없으면 완전히 종료한다.

이 둘은 비슷하지만 호출되는 시기에 따라 다른 방식으로 동작한다.

• setImmediate() : 현재 폴링 단계가 완료되면 스크립트를 실행하도록 설계
• setTimeout() : 최소 임계값(ms)이 경과한 후 스크립트가 실행되도록 예약한다.

타이머가 실행되는 순서는 컨텍스트에 따라 다르다. 둘 다 기본 모듈 내에서 호출되는 경우 타이밍은 프로세스의 성능에 의해 제한된다. (시스템에서 다른 응용프로그래밍의 영향도 받을 수 있음)

예를 들어, I/O cycle(예. 메인모듈)안에 있지 않은 아래와 같은 스크립트를 실행한다면, 두 타이머가 실행되는 순서는 프로세스의 성능에 의해 제한되기 때문에 비결정적이다.

// timeout_vs_immediate.js
setTimeout(() => {
    console.log('timeout');
}, 0);

setImmediate(() => {
    console.log('immediate');
});

$ node timeout_vs_immediate.js
timeout
immediate

$ node timeout_vs_immediate.js
immediate
timeout

그러나, 두 호출을 I/O cycle 안으로 옮기면, immediate 콜백이 항상 먼저 수행된다.

const fs = require('fs');

fs.readFile(__filename, () => {
    setTimeout(() => {
	console.log('timeout');
    });
    setImmediate(() => {
	console.log('immediate');
    });
});

$ node timeout_vs_immediate.js
immediate
timeout

$ node timeout_vs_immediate.js
immediate
timeout

setImmediate 이 setTimeout 보다 가지는 이점은, setImmediate() 는 몇개를 갖고 있던 I/O cycle(주기) 안에서 예약되면 타이머보다 항상 먼저 실행된다는 것이다.

기술적으로보면 process.nextTick() 은 이벤트 루트의 일부가 아니다. 대신 nextTickQueue 는 현재 작업이 끝나면 실행되는 녀석이다. 이것은 현재 이벤트 루프가 어떤 페이즈에 있건 상관없다. 여기에서 작업이란 기본 C/C++ 핸들러에서 전환하여 실행되야하는 javascript를 처리하는 것이다.

다이어그램을 보자, 주어진 페이즈(현재 페이즈)에서 process.nextTick() 이 호출될 때마다, process.nextTick() 으로 들어온 콜백들은 이벤트 루프가 진행되기 전에 해결된다. 이것은 이벤트 루프가 poll 페이즈에 도달하는 것을 막는 상황을 만들 수도 있다. process.nextTick() 을 재귀적으로 호출하여 I/O를 굶주리게(starve) 만드는 것이 그것이다.

왜 이것이 허용되었을까?

그 중 일부는 API가 반드시 비동기식일 필요가 없는 경우에도 항상 비동기식이어야 하는 설계 철학때문이다.

function apiCall(arg, callback) {
    if (typeof arg !== 'string') 
	return process.nextTick(
	    callback,
	    new TypeError('argument should be string')
	);
}

이 경우 arg 를 확인하고 올바르지 않은 경우 콜백에 오류를 전달한다. API는 최근 업데이트되어 process.nextTick() 에 인수를 넣을 수 있도록 하였다. 이것으로 콜백 이후 전달된 이후를 콜백에 인수로 전달하여 함수를 중첩할 필요가 없어졌다.

우리가 하려는 것은 사용자에게 Error를 다시 전달하는 것이다. 그러나 사용자 코드의 나머지 부분이 실행되도록 허용 한 후에만 가능하다.

process.nextTick() 로 apiCall() 이 항상 유저 코드의 나머지가 실행된 이후와 이벤트 루프가 처리를 시작하기 전에 콜백을 실행하도록 한다. 이렇게 하기 위해 JS call stack은 풀어버리고 콜백들을 즉시 실행할 수 있는 것을 허용한다. 이것으로 process.nextTick() 의 재귀호출을 가능하게 만든다. RangeError: Maximum call stack size exceeded from v8. 라는 에러 없이.

이 철학은 잠재적으로 문제를 일으킬 수 있다.

let bar;

// this has an asynchronous signature, but calls callback synchronously
function someAsyncApiCall(callback) {
    callback();
}

// the callback is called before `someAsyncApiCall` completes.
someAsyncApiCall(() => {
  // since someAsyncApiCall hasn't completed, bar hasn't been assigned any value
  console.log('bar', bar); // undefined
});

bar = 1;

사용자가 someAsyncApiCall() 를 비동기 시그니처를 정의하여도, 동기적으로 작동한다. 호출이 될 때, someAsyncApiCall() 에 제공된 콜백은 이벤트 루프와 동일한 페이즈에서 호출된다. 이는 someAsyncApiCall() 이 실제로는 비동기적으로 아무것도 수행하지 않기 때문이다. 결과적으로, 콜백은 스크립트가 완료될 때까지 실행되지 못했기 때문에 변수가 없을지라도 bar 의 참조를 시도한다.

process.nextTick() 으로 콜백을 바꾸면, 스크립트는 완료될 때까지 실행되어 '콜백이 호출되기 전에' 모든 변수, 함수 등을 초기화할 수 있다. 이것의 장점은 이벤트 루프로 넘어가지 않도록 허용하지 않는다는 것이다. 이것은 이벤트루프로 넘어가기 전에 에러를 유저에게 알려주고 싶을 때 유용하다. 아래 코드가 process.nextTick() 을 사용한 코드다.

let bar;

function someAsyncApiCall(callback) {
    process.nextTick(callback);
}

someAsyncApiCall(() => {
  console.log('bar', bar); // 1
});

bar = 1;

아래는 또 다른 리얼월드 예시다.

const server = net.createServer(() => {}).listen(8080);

server.on('listening', () => {});

포트만 주어진 경우, 포트는 즉시 반영된다. 하여 'listening' 콜백이 즉시 호출될 수 있다. 문제는 .on('listening') 콜백이 그때까지 설정되지 않았다는 것이다.

이 문제를 해결하기 위해 스크립트가 완료될 때까지 실행될 수 있도록 'listening' 이벤트가 대기열(큐)에 추가된다. nextTick() 을 통해 사용자가 원하는 이벤트 핸들러를 설정할 수 있다.