What is the difference between Child_process and Worker Threads?

이 글은 stackoverflow에 작성된 What is the difference between Child_process and Worker Threads? 의 질문과 답변을 한국어로 번역한 글입니다.

I am trying to understand Threading in NodeJS and how it works.

나는 NodeJS 안에 있는 Threading 것이 어떤 것이고 어떻게 작동하는지 이해하려하고 있다.

Currently what i understand:

지금 내가 이해한 것들 :

Cluster: -

클러스터:

• Built on top of Child_process, but with TCP distributed between clusters.

Child_process 맨 위에 지어지지만 클러스터간에 TCP가 분산되어 있습니다.

• Best for distributing/balancing incoming http requests, while bad for cpu intensive tasks.

들어오는 http 요청을 distributing(분배)와 balancing (균형) 을 맞추는데는 적합하지만 반면에, CPU 집약적 업무에는 안좋다.

• Works by taking advantage of available cores in cpu, by cloning nodeJS webserver instances on other cores.

(Cluster는) cpu 안에 있는 사용가능한 코어들을 사용하는 장점을 가지면서 그리고 다른 코어의 nodeJS webserver instances 를 복사하면서 작동한다

Child_process:

• Make use also of different cores available, but its bad since it costs huge amount of resources to fork a child process since it creates virtual memory.

다른 코어를 사용가능하게 만들지만 a child process를 fork(복사) 하기위해 가상 메모리를 만들어 어마어마한 자원이 필요하기 때문에 안좋다.

• Forked processes could communicate with the master thread through events and vice versa, but there is no communication between forked processes.

fork 된 processe 들은 master thread 와 이벤트들을 통해서 소통할수 있지만 반면에 fork된 processe 들 사이에선 커뮤니케이션이 없다.

Worker threads:

• Same as child process, but forked processes can communicate with each other using bufferArray

child process 와 비슷하지만 fork 된 processes 들이 커뮤니케이션 할수 있다. bufferArray 를 이용하여서.

1) Why worker threads is better than child process and when we should use each of them?

1) 왜 worker threads 가 child process 보다 좋냐. 그리고 언제 쓰냐

2) What would happen if we have 4 cores and clustered/forked nodeJS webserver 4 times(1 process for each core), then we used worker threads (There is no available cores) ?

2) 4 코어에 forke 된 nodejs 웹서버 4개 (한개의 코어에 한개) 를 가지고 있다면 그때 `worker threads 를 쓴다면 무슨일이 벌어지나?

답변

Sounds like the classical tradeoff between threads and processes.

스레드와 프로세스는 classical tradeoff 처럼 들린다. (양립할 수 없다 라는 뜻 같음 물물교환이라는 뜻인데 느낌은 잘 안옴.)

Threads share the same memory space, so context switch is faster (basically, just the register contents are saved per thread).

스레드는 같은 메모리공간을 공유하고 그렇기 때문에 context switch 가 빠르다. ( 기본적으로 하나의 레지스터 저장소는 하나의 스레드를 저장하고있다.)

However, synchronizing between them and ensuring mutual exclusion (global data integrity) is under your own responsibility (as a programmer).

그러나 그들과의 동기화와 mutual exclusion(전역 변수가 오염되지 않는 것을 말하는 거 같음)의 확신은 너의 책임에 있다.

Processes run in different memory spaces, so mutual exclusion is guaranteed by the OS, but context switch is slower of course.

프로세스들은 다른 메모리공간에서 작동한다. 그래서 mutual exclusion 가 OS에 의해서 보장된다. 그러나 당연히 context switch 는 느려진다.

2 Answer

You mentioned point under worker-threads that they are same in nature to child-process. But in reality they are not.

너는 워커스레드가 child-process랑 완전히 같다고 설명했는데 그거 아님

Process has its own memory space on other hand, threads use the shared memory space.

프로세스는 고유의 메모리공간이 있다. 반명에 스레드들은 공간을 공유한다.

Thread is part of process.

스레드는 프로세스의 부분이다.

Process can start multiple threads. Which means that multiple threads started under process share the memory space allocated for that process.

프로세스는 멀티 스레드로 시작할수 있다, 그 말은 프로세스에서 시작된 여러 스레드가 해당 프로세스에 할당 된 메모리 공간을 공유한다는 뜻이다.

I guess above point answers your 1st question why thread model is preferred over the process.

나는 위의 포인트가 너의 첫번째 질문인 왜 스레드 모델이 프로세스 모델보다 더 선호되는가 에대한 답변이라고 생각한다.

2nd point: Lets say processor can handle load of 4 threads at a time. But we have 16 threads. Then all of them will start sharing the CPU time.

2번째 포인트: 프로세서가 저장된 4개의 스레드들을 다룬다고 가정하자. 그러나 우리는 16개의 스레드가 있다. 그리고 모든건 cpu time 을 공유할 것이야.

Considering 4 core CPU, 4 processes with limited threads can utilize it in better way but when thread count is high, then all threads will start sharing the CPU time.

4 코어 CPU를 고려하면 스레드가 제한된 4 개의 프로세스가 더 나은 방식으로 활용할 수 있지만 스레드 수가 많으면 모든 스레드가 CPU 시간을 공유하기 시작해.

(When I say all threads will start sharing CPU time I'm not considering the priority and niceness of the process, and not even considering the other processes running on the same machine.)

(모든 스레드가 CPU 시간을 공유하기 시작한다고 말할 때 프로세스의 우선 순위와 우수성을 고려하지 않고 동일한 시스템에서 실행되는 다른 프로세스도 고려하지 않았다)

My Quick search about time-slicing and CPU load sharing:

1. https://en.wikipedia.org/wiki/Time-sharing
2. https://www.tutorialspoint.com/operating_system/os_process_scheduling_qa2.htm

This article even answers how switching between processes can slow down the overall performance.

이 기사들은 프로세스간 전환이 어떻게 퍼포먼스를 낮추는지에 대한 답변들입니다.

Worker threads are are similar in nature to threads in any other programming language.

워커 스레드는 본질적으로 다른 프로그래밍의 스레드와 유사하다.