이벤트 루프

https://meetup.nhncloud.com/posts/89

자바스크립트와 이벤트 루프 : NHN Cloud Meetup

https://www.korecmblog.com/node-js-event-loop/

Node.js 이벤트 루프(Event Loop) 샅샅이 분석하기

---

프로그래밍 패턴

이벤트 루프란 프로그래밍 패턴. V8에서는 외부 이벤트 루프 구현을 플러그인하여 JS 런타임과 함께 작동할 수 있다.

Chrome 브라우저는 이벤트루프 구현으로 libevent를 사용, NodeJS는 libuv를 사용.

자바스크립트가 '단일 스레드' 기반의 언어라는 말은 '자바스크립트 V8엔진이 단일 호출 스택을 사용한다'는 관점에서만 사실이다.

실제 자바스크립트가 구동되는 환경(브라우저, Node.JS 등)에서는 주로 여러개의 스레드가 사용되며, 이러한 구동 환경이 단일 호출 스택을 사용하는 자바 스크립트 엔진과 상호연동하기 위해 사용하는 장치가 바로 '이벤트 루프'.

 

작동방식

- 비동기코드는 콜스택에서 사라진다. (ajax, 이벤트 리스너 등)

- 태스크 큐에 들어간다. 여러개의 태스크 큐가 존재.

- 태스크 큐는 콜백함수들이 대기하는 큐(FIFO)형태의 배열.

-이벤트 루프는 호출스택이 비워질 때마다 큐에서 콜백함수를 꺼내와서 실행하는 역할.

-이벤트 루프는 현재 실행중인 태스크가 없을 때 (호출 스택이 비워졌을 때) 태스크 큐 첫번째 태스크를 꺼내와 실행한다.

 

---

NodeJS의 이벤트 루프

- libuv란 c++로 작성된, Node.JS가 사용하는 비동기 I/O 라이브러리. 

- 이는 OS의 커널을 추상화한 Wrapping 라이브러리. 커널이 어떤 비동기 API를 지원하는지 알고 있다.

- libuv는 기본적으로 4개의 스레드를 가지는 스레드 풀 생성. (uv_threadpool 라는 환경변수를 설정해 최대 128개 까지 스레드 개수를 늘릴 수도 있다.)

- libuv에게 비동기 작업을 요청하면 libuv는 이 작업을 커널이 지원하는지 확인, 지원하면 커널에 비동기적으로 요청했다가 응답 전달

- 커널이 지원하지 않으면, 자신만의 워커스레드가 담긴 스레드 풀을 사용.

 

 

- nextTickQueue, microTaskQueue 는 이벤트 루프의 일부가 아니다.

- 이벤트 루프는 1.Timer Phase, 2.Pending Callbacks Phase, 3.Idle Prepare Phase, 4.Poll Phase, 5.Check Phase, 6.Close Callbacks Phase 로 구성되어 있다.

- 1->2->3->4->5->6->1 순서.

- 한 페이즈에서 다음 페이즈로 넘어가는 것을 틱Tick이라 한다.

- 각 페이즈는 자신만의 큐를 하나씩 가지고 있다. 이 큐에 이벤트 루프가 실행해야 하는 작업들이 순서대로 담겨 있다.

- 단, 이벤트루프가 비동기 실행을 하는 것과 별개로 Node.js는 싱글 스레드. 하나의 페이즈에만 진입, 한번에 하나의 작업만!

- Poll phase 작업을 처리하면서 Check Phase 작업을 동시에 처리하거나 하는 것은 불가능하다.

- Node.js는 순서대로 페이즈를 방문하면서 큐에 쌓인 작업을 하나씩 실행한다. 

- 페이즈 큐에 담긴 작업을 모두 실행하거나 시스템 실행한도에 다다르면 Node.js는 다음 페이즈로 넘어간다.

- 쌓인 작업을 처리하던 중 이전 페이즈에서 실행했던 작업의 콜백이나 커널이 스케줄링한 새로운 작업이 큐에 추가될 수 있다.

- Node.js가 큐에 계속 추가되는 작업을 처리하느라 다음 페이즈로 넘어가지 못할 수 있다. 그러나, 페이즈는 시스템 실행한도의 영향을 받으므로 한 페이즈에 영원히 갇히는 일은 없다.

 

---

이벤트 루프의 여러 페이즈

1. Timer Phase

- Timer Phase : 타이머에 대한 비동기작업들을 관리한다. setTimeout, setInterval 등.

- Timer phase는 큐에 콜백을 직접 담지는 않는다. 대신 콜백을 언제 실행할지 정보가 담긴 타이머를 Timer Phase가 관리하는 min-heap에 넣는다. 만약 Poll Phase에서 setTimeout을 3번 호출했다면 Timer Phase의 min-heap에 3개의 타이머가 저장되어 있다. 그리고 시간이 되면 타이머가 가리키고 있는 콜백을 호출한다. 

- 최소 힙 min heap은 데이터를 완전 이진트리 형태로 관리, 최댓값 최솟값 찾아내는데 효율적인 자료구조. 최대 힙 max heap 은 최댓값, 최소 힙 min heap 은 최솟값에 최적화.

- Timer Phase에 진입해야만 타이머들은 실행기회를 얻음 (따라서 Poll Phase에서 setTimeout(fn, 1)을 호출한다 해도 Node.js는 정확히 1ms 뒤에 콜백이 실행됨을 보장하지 않는다. Timer Phase에 진입하는데 1초가 걸린다면 타이머의 콜백을 실행하는 데는 1ms가 아니라 1초 이상이 걸리게 된다.)

- Timer Phase는 큐에 있는 모든 작업을 실행하거나 시스템의 실행 한도에 다다르면 다음 페이즈로

- Node.js가 Timer Phase에 진입하면 min-heap에서 타이머를 하나 꺼낸다. 그리고 그 타이머에 대해서 now - registeredTime >= delay 조건을 검사한다. 만약 만족한다면 타이머를 실행할 준비가 되었으므로 타이머의 콜백을 실행한다. 그리고 다시 min-heap에서 타이머를 꺼내서 검사한다. 만약 조건이 성립하지 않는다면 남은 타이머들을 검사하지 않고 다음 페이즈로 넘어간다. 그 이유는 min-heap이 타이머를 오름차순으로 관리해 검사할 필요가 없기 때문이다.

여러 블로그에서  Timer Phase는 타이머만 관리하고  Poll Phase에서 콜백이 실행된다고 기술했다. 하지만 이는 사실이 아니다. Timer Phase에서 타이머를 검사하고 실행도 한다. 

페이즈가 아닌 nextTickQueue의 경우 시스템의 실행 한도의 영향을 받지 않기 때문에 Node.js가 영원히 갇혀 다음 페이즈로 이동하지 못할 수 있다.

 

 

2. Pending Callbacks Phase

- pending_queue 에 담기는 콜백 관리, 이 큐에 담기는 콜백들은 이전 이벤트 루프 반복에서 수행되지 못했던 I/O 콜백

- 시스템 실행한도 제한에 의해 넘어간 작업들을 쌓아놓고 실행하는 페이즈

- 펜딩 큐에 담겨있는 콜백 없다면 다음 페이즈로

- 펜딩 큐에 콜백이 있다면 시스템 실행한도 넘기 전까지 큐에 있는 모든 콜백 순서대로 실행

 

3.Idle, Prepare Phase

- Node.js 내부관리 위한 페이즈, 코드의 직접적인 실행에 영향을 미치지 않는다

 

4.Poll Phase 

- 새로운 I/O 이벤트를 다룸, watcer_queue 의 콜백들 실행, I/O에 대한 거의 모든 콜백들이 담김

- setTimeout, setImmediate, close 콜백 등을 제외한 모든 콜백이 여기서 실행

- 예컨대 DB쿼리 후 결과 왔을 때 실행되는 콜백, HTTP 요청 후 응답 왔을 때 실행되는 콜백, 파일을 비동기로 읽은 후 실행되는 콜백

- Poll Phase 콜백 관리

- I/O 이벤트는 타이머와 달리 큐에 담긴 순서대로 I/O 작업이 완료되어 콜백 또한 차례대로 실행된다는 보장이 없다. 

- 실행 시간을 가지고 있던 타이머와 달리 I/O 이벤트는 event loop 혼자서는 언제 완료되었는지 알 수 없다. 이런 문제를 해결하기 위해 Poll Phase는 단순한 콜백 큐를 사용하지 않는다.

 

5.  Check Phase

- 오직 setImmediate 의 콜백만을 위한 페이즈

- setImmediate 가 호출되면 Check Phase의 큐에 담기고 진입하면서 차례대로 실행

cf) 이름과 달리 process.nextTick은 같은 페이즈에서 호출한 즉시 실행, setImmediate는 다음 틱 실행, Check Phase 의 큐에 담기고 Node.js가 Check Phase에 진입하면 차례대로 실행

 

6. Close Callbacks Phase

- socket.on('close', () => {});과 같은 close 이벤트 타입의 핸들러를 처리하는 페이즈

- 시스템 실행 한도를 초과하기 전까지 closing_handles에 담긴 작업을 순서대로 실행한다.