인프런 커뮤니티 질문&답변
작성한 질문수
Session #1에서 owner를 이용한 레퍼런스 관련한 부분 질문입니다.
해결된 질문
작성
·
76
0
몇 년 전에 강의를 들었을 때 느꼈던 거랑 요새 다시 들으면서 느끼는 게 많이 다르네요. 새삼 코드 퀄리티가 너무 좋습니다. 감사합니다.
레퍼런스 카운트 관련해서 궁금한 점이 있습니다. Session 객체는 Service의 sessions에서 관리하는 한, 비동기 IO 작업 중에 메모리가 해제될 일은 없을 거라고 생각되는데요.
그럼에도 불구하고 이벤트 객체에 owner 객체를 둬서 레퍼런스 카운트를 1을 올려놓은 채로 작업을 진행하는 건 정말 혹시 모를 상황에 대한 대비일까요?
연결이 끊어져야 sessions에서 세션 객체를 꺼내니까(~Session 소멸자 호출 확인) 웬만한 상황에서는 비동기 IO 중에 세션 객체가 날아갈 일은 없을 것 같단 생각이 들었습니다. 만약 그 상황에 대한 대비라면 지금 구조에서는 ProcessRecv가 시작하자마 nullptr으로 밀어버리는 것도 RegisterRecv()를 호출하기 직전으로 옮겨야 하지 않나 하는 생각도 들었습니다. 고견을 듣고 싶습니다!
감사합니다!
답변 2
1
레퍼런스 카운트 관련해서 궁금한 점이 있습니다. Session 객체는 Service의 sessions에서 관리하는 한, 비동기 IO 작업 중에 메모리가 해제될 일은 없을 거라고 생각되는데요.
-> Service에서 sessions로 평생 관리하는 것이 아닙니다. 가령 해당 유저가 접속을 끊거나, 핵으로 의심되어 서버에서 강제로 킥하는 등의 상황이라면 Service 매니저 쪽에서도 제거하니, 이 때 걸어둔 네트워크 IO가 있으면 난리가 나겠죠.
1
안녕하세요, 인프런 AI 인턴입니다. literate_t님.
Session 레퍼런스 카운트와 관련한 질문에 대해 깊이 있는 이해를 목표로 하시는 모습이 인상적입니다.
질문에서 말씀하신 것처럼, 세션 객체가 서비스의 session 리스트에 존재하는 동안에는 비동기 IO 작업 중에 메모리가 해제될 걱정이 거의 없다고 볼 수 있습니다. 하지만 현재 구조에서 owner로 설정하여 레퍼런스 카운트를 올려두는 방식은 세션이 예기치 않은 상황에서도 안전하게 유지될 수 있도록 하는 방어적 프로그래밍의 일환입니다.
비동기 IO 작업은 일반적으로 여러 가지 상황이 겹칠 수 있기 때문에, 안전한 메모리 관리가 필요합니다. 따라서, 이벤트 객체가 세션의 레퍼런스 카운트를 유지하여 작업 중에도 해당 세션이 유효하게 유지될 수 있도록 설계된 것입니다. 이는 잠재적인 버그나 의도하지 않은 메모리 해제를 피하기 위한 아주 좋은 방법입니다.
레퍼런스 카운트를 RegisterRecv 호출 직전으로 옮기는 제안은 관련 코드 흐름을 더욱 직관적으로 만들 수 있지만, 현재 설계는 데이터 수신 작업이 끝난 후에도 잠시 동안 메모리 관리가 자동으로 이루어지도록 하는 데에 중점을 두고 있습니다. 따라서 실제 구현에서 어떤 방식을 채택할지 결정하기 위해서는 각 방식의 장단점을 검토해 보시는 것이 좋습니다.
더 자세한 설명을 원하신다면, 다음의 유사한 질문의 답변들을 참고해 보시기 바랍니다:
- [session의 생명주기 관련 질문입니다.] - 세션의 수명과 레퍼런스 카운트 관리에 대한 심도 있는 논의가 이루어진 게시물입니다.
- [SendBufferRef에 대하여 질문 있습니다.] - 레퍼런스 카운트의 중요성과 관리 방법에 대한 추가적인 통찰을 얻을 수 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
감사합니다! 조금 더 구체적인 상황이 궁금했습니다👍🏻