non block IO의 advantage는 무엇인가? [번역]

아래 페이지에 대한 번역이다

https://www.quora.com/What-are-the-advantages-of-non-blocking-IO

오역이 많을 것으로 예상되오니 태클 및 지적은 환영합니다

non block IO를 사용하면 IO request와 실제 IO작업(actual delivery)를 분리할 수 있다. 결과적으로 우리는 request task를 계속 진행할 수 있다

request file

do

something else

until file is there

file을 읽어오는 방법은 2가지가 있다.

하나는 blocking IO를 사용하여 file을 다 읽어올 때까지 기다리는 것,

다른 하나는 file을 다 읽어올 때까지 loop를 도는 것인데, 이 loop는 busy loop가 되거나 event driven으로 처리할 수 있다

이것은 데이터가 읽어졌을 때, request file 커맨드가 event를 발생시키고 프로그램이나 함수를 실행하는 것을 의미한다

대부분의 GUI에서 non block IO를 볼수 있는데, menu에서 오는 모든 것들이 event driven인 부분에서 볼수 있다

Java에는 event driven으로 동작하지 않는 나쁜 예시들이 있으며, 잘못 작성된 GUI event 응답 코드 ㅡ 몇몇 Java 관련 서적에서 논의되고 있는 ㅡ 로부터 "Java는 느리다"라는 불만이 있다

But that’s not just true for Java, but there it’s very obvious when it happens

대부분의 전통적인 프로그래밍 훈련들은 bad blocking IO로 접근하기 때문에,

당신이 프로그래머로서 시작하고 학교에서 나왔다면,

실용적이고 modern한 S/W를 작성할 때 기초부터 다시 배워야 합니다

특히 GUI같은 느린 IO (사람에 의한 입력)이나 네트워크 IO를 이용하는 어떤 프로그램을 작성할 때는 특히 더 그렇다

하지만 대부분의 IO와 flow hog라고 볼수있는 (느린) 연산에도 해당하는 이야기이다

Always try to spawn number crunching off your main process like everything that takes time and create an event for the moment when it’s ready.

이것은 애플리케이션의 반응성에 의한 트러블로부터 안전해질 뿐만 아니라 이것은 "연산을 병렬처리하는 멀티프로세싱"을 구현하기 위한 좋은 단계(step)이다

이 다음에 논리적인 단계가 있습니다

Event-driven program structures are more or less what you need on modern systems,

하나 예외는 리눅스에서 shell 기반의 입력-연산-출력 구조의 프로그램이다

이것은 왜 리눅스에서 프로그래밍하는 것이 아주 쉬운 이유이고 적은 코드로 문제를 해결할수있는 이유이다 : 쉬운 흐름 구조 덕분이다

하지만 OS는 여전히, 어쨌든 kernel level에서는 non blocking IO를 할것이고, 단지 프로그램은 blocking IO call에서 block될 것이다

이것은 이전에 논의된 방식이다

특정한 모던 언어들은 non blocking IO를 더 쉽게 만들려고 노력하고 있다 (애플리케이션 레벨에서), Javascript처럼

하지만 필자는 그것이 일반적으로 가능하다고 생각하지 않는다

이것은 그저 JS에서만 잘 작동하는 것이다, 왜냐하면 JS는 주로 event-driven 방식으로 동작하는 GUI 기반 언어이기 때문이다

이것을 native로 하는 또다른 유일한 언어는 AWK이다. 이것은 당장 만나볼 수 있다 (come up)

AWK는 프로그램이 복잡해지고 사이즈가 증가할 때마다 messy해진다는 점에서 비판받는다

그리고 모든 event-driven GUI 기반 프로그램들도 마찬가지이다

GUI driven 프로그램은 데이터 흐름을 이전 또는 이후로 엉망으로 만들고(mess up) AWK에서 이미 발견된 동일한 문제들과 fight하기(싸우기) 시작한다

그러므로 event-driven 프로그래밍 구조를 train하길 원한다면 there is hardly a way around something like AWK

event driven 방식이 메인인 다른 언어들(특히 JS같은)을 찾을지도 모른다, 하지만 많지는 않다.

실제로 (in effect) AWK로 구현한 것같은 상태머신(state-machine)이 얻어지는데, 그것이 바로 event-driven non-blocking IO 프로그램을 구현하기 위한 것이다

무슨 일이 일어나고있는지 추적(track)은 가능하지만, 조심해야하고 스스로 train해야한다. 그렇지않으면 프로그램이 복잡해질수록 심각한 트러블을 겪을 것이다

이것과 느슨하게 연관된 각 문제들이(메모리 누수, 가끔씩 발생하는 NULL 포인터 예외같은) 시작하면 빈번한 가비지 컬렉팅 등등 수많은 very ugly bugs의 원인을 찾는것이 드럽게 힘들다(ugly hard)

진짜로 힘들다. 왜냐하면 디버거를 통해 그 원인들을 찾는것에 문제가 있기 때문이다.

디버거는 전통적인 제어-흐름 구조에서 최고로 잘 동작하지만 event-driven 구조에서는 딱히 그렇지 않다

My tip: AWK를 배워라 그리고 잠깐 AWK를 가지고 놀아봐라(play). 이것은 프로그램 플로우를 생각하는 방식을 바꿀 것이다. 그리고 그 후에는 그 지식을 어떤 GUI-driven 애플리케이션에든지 쉽게 이식(port)할 수 있을것이다

----

대략적인 내용흐름은 non-blocking IO -> GUI event-driven -> program complexity -> AWK인듯하다

결론적으로 non-blocking IO는 GUI event-driven이나 Network같은 IO를 처리할 때 반응성 또는 병렬처리 면에서 효과적(advantage)이다

대신 프로그램이 복잡해지는 것은 어쩔수 없으므로 AWK를 먼저 접해보는 것을 tip으로 조언하고 있다

(필자는 AWK는 사용한 적이 없어서 event-driven과 어떤 연관인지 잘 모르겠으나)