24.06.02 19:43 작성
·
130
0
안녕하세요, context의 read와 write 부분을 듣다 궁금한 점이 생겨 질문을 남깁니다.
Context는 체인이 맨 아래에서부터 위로 전파된다는 내용은 이해했습니다.
궁금한 점은 'Context read 읽는 동작이 Context write 동작 밑에 있을 경우에는 write된 값을 read할 수 없'는 동작을 컴퓨터는 어떻게 이해하고 실행하는지를 모르겠습니다. 위에서부터 아래로 코드를 읽어나가면 contextWrite()는 마지막에 읽히게 되니까요.
컴파일하면서 write의 위치가 바뀌어 write가 먼저 진행되는지 혹은 subscribe()를 만나기 전까지는 실제 stream이 동작하지 않아 write된 값이 저장돼 있는지..코드 작동 순서/원리가 궁금합니다.
감사합니다.
답변 2
1
2024. 06. 02. 22:07
안녕하세요? Context가 왜 아래에서 위로 전파되는지에 대한 부분은 아래 AI 인턴의 답변을 참고하시면 될 것 같구요.
질문자님이 궁금해 하시는 건 코드가 위에서 아래로 순차적으로 읽어나가는데 read가 write 밑에 있으면 write된 값을 왜 read 할 수 없는지를 궁금해 하신다고 이해했습니다.
Reactor의 코드 내부에서는 복잡한 과정을 거치긴 하겠지만 핵심은 람다 표현식(함수형 인터페이스)에 있다고 생각합니다.
우리가 명령형 프로그래밍 방식에서 작성하는 코드는 작성한 순서대로 위에서 아래로 실행됩니다. 즉 코드가 순차적으로 즉시 실행된다고 생각하시면 될 것 같은데요.
Java의 Stream API나 리액티브 프로그래밍의 경우에는 명령형 프로그래밍 방식처럼 메서드 체인 형태로 순차적으로 실행되는 것 같지만 Operator 함수로 넘겨준 람다 표현식이 즉시 호출되지는 않고 지연 호출이 가능합니다.
단순히 하나의 람다 표현식에 대해서만 지연 호출이 가능하다면 순차적으로 실행되면 약간 딜레이를 주고 실행된다고 볼 수 있지만
Stream API나 리액티브 프로그래밍 같은 경우에는 람다 표현식을 딱 하나만 함수의 파라미터로 전달하는게 아니라 메서드 체인 형태로 각 Operator 함수에서 거의 매번 전달 하는 형태인데 이 때, Operator 함수에서 전달 받은 람다 표현식은 일반적으로 위에서 아래로 순차적으로 실행되지는 않거든요.
문장으로 설명드리니 이해하기가 어려우실텐데 간단히 코드로 표현을 하면 아래와 같습니다.
Flux.just(데이터 소스)
.operator1(op1-lambda)
.operator2(op2-lambda)
.operator3(op3-lambda)
.subscribe()
위 코드에서 operator1이 operator2를 호출하고 operator2가 operator3을 차례대로 호출하는건 맞는데 operator1, 2, 3에서 각각 파라미터로 전달한 op1-lambda, op2-lambda, op3-lambda 표현식은 구독이 발생하기 전까지는 호출이 지연된다고 볼 수 있습니다.
람다 표현식의 가장 중요한 특징 중 하나가 지연 호출입니다.
그런데 지연 호출된다고 해서 op1-lambda -> op2-lambda -> op3-lambda 의 순서대로 실행이 되는게 아니라 일반적으로 op3-lambda -> op2-lambda -> op1-lambda 형태로 역으로 호출됩니다.
이렇게 호출 할 수 있는 이유는 내부적으로 op2-lambda가 op1-lambda의 참조를 가지고 있고, op3-lambda가 op2-lambda의 참조를 가지고 있어서 역으로 호출이 가능하다라고 생각하시면 될 것 같습니다.
리액티브 프로그래밍이 이렇게 역으로 호출되어 아래쪽에서 위쪽으로 동작이 전파되는 특성을 가지고 있는데 검색해 보시면 구독이 아래에서 위로 전파된다
라는 내용을 심심치 않게 보실 수 있을텐데 Context의 동작도 구독의 동작에 맞춰서 일어난다고 보시면 될 것 같습니다.
질문하신 부분에 대한 충분한 답변이 되셨길 바랍니다.
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
harper.2님께서 문의하신 context의 read와 write의 실행 순서와 관련하여, 동일한 주제에 대해 유사한 질문과 답변이 있어 링크를 공유합니다. 이는 context의 작동 방식과 stream이 실제로 어떻게 처리되는지에 관한 궁금증을 해결하는 데 도움을 줄 수 있을 것입니다.
”.contextWrite의 실행시점”에서는 contextWrite가 코드의 순서와 상관없이 먼저 발생하여 context에 값을 저장하고, 이후에 Mono.deferContextual가 실행되어 ctx에서 contextWrite에서 했던 값을 가져온다는 질문에 대한 답변을 포함하고 있습니다. Kevin 강사님은 context에 대한 깊은 설명과 함께 인증 정보나 환경 설정 값과 같은 직교 정보가 contextWrite 통해 저장되어 upstream에서 이를 최신 정보로 이용하는 방식에 대해 설명하십니다.
Context 체인 전파 질문에서도 context가 왜 아래에서 위로 전파되는지에 대한 궁금증에 대해 답변이 제공되었습니다. Kevin 강사님은 RxJava나 Project Reactor의 Operator 체인이 어떻게 작동하는지, 그리고 context의 전파 특징에 대해 설명합니다.
이러한 답변들은 Reactive Programming에서 context의 동작 방식에 대한 이해를 돕는데 유용할 것이며, contextWrite와 contextRead의 실행 순서 및 이들이 코드 상에서 어떻게 처리되는지에 대한 궁금증을 해결하는 데 기여할 수 있을 것입니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
2024. 06. 02. 19:58
링크로 공유된 질문들은 주로 '왜 upstream으로 전달이 되는가'로 이해됩니다.
제가 궁금한 부분은 '어떻게'로, 섹션5 backpressure에서 프로세스를 설명해주신 것처럼 context에 대한 좀 더 자세한 프로세스가 궁금합니다.