[Service강의] owner - shared_ptr

Question

아직 다음 강의를 안들어서 잘 예측이 안되지만, owner에 보통 이벤트를 발생시킨 Session의 shared_from_this()를 넣어줄 것으로 예상을 해봅니다. 만약 이 상황에서 io작업이 밀려 오래 걸리거나 누락되어 shared_ptr로 물고 있던 session들이 해제 안되는 문제가 생길 수 있지 않나요? 그렇기 때문에 weak_ptr로 owner을 관리하고, 다만 session이 만료되어 없어지면 유효하지 않은 이벤트이므로 .lock()을 통해 nullptr로 반환 시 예외 처리해주는게 더 안전하지 않나요? 공부를 더 해야겠지만, 사실 아직 잘 이해가 안갑니다. owner와 event등의 수명 주기가 어떤 관계가 있는지 정확히 모르겠지만 방향성을 알려주시면 감사하겠습니다.

Rookiss · Answer

기본적으로 비동기 네트워크 이벤트에는 만료 시간이 설정되어 있어 실패를 했으면 했지, 무한으로 밀리진 않습니다. 따라서 우려하신 부분은 일어나지 않습니다. 오히려 반대로 이벤트를 발생시킨 후 결과가 나올 때까진 절대 Session 객체를 날리면 안 됩니다. (왜냐하면 Session에 이벤트 내부에서 사용하는 recv/send버퍼가 있을 수 있기 때문. 이러면 커널에서 유저레벨로 접근하는 타이밍에 크래시가 날 수 있습니다.) shared_ptr를 넣은 것은 강의에서 제가 슬쩍 시도해본 방법이지만, 꼭 그렇게 안 하더라도 일종의 이벤트 등록 횟수에 대한 RefCount를 Session에서 따로 관리해 처리하는 경우도 많았습니다.

communityai8509 · Answer

안녕하세요, 인프런 AI 인턴입니다. 서정원님. 세션 객체를 shared_ptr 로 관리하는 경우에는 말씀하신 것처럼 refcount 에 의해 세션이 만료되었음에도 불구하고 참조가 남아있어 문제가 발생할 수 있습니다. 이는 특히 비동기 IO 작업을 처리할 때 예상치 못한 상황을 초래할 수 있습니다. 이 경우, weak_ptr 를 사용하여 세션의 참조를 유지하고 필요할 때만 lock() 을 이용해 실제 객체를 참조하는 방식이 더 적절할 수 있습니다. weak_ptr 는 참조 횟수에 영향을 주지 않으면서도 세션 객체가 아직 유효한지 확인할 수 있게 해주기 때문에, 만약 세션이 이미 제거된 상태라면 lock() 시도 시 nullptr 을 반환하여 자연스럽게 문제를 방어할 수 있습니다. 이와 관련하여 도움이 될 만한 기존 질문과 답변들을 안내드립니다: Session의 수명 관리를 위한 Ref 카운트 관리 부분 - 여기에서 shared_ptr 와 참조 카운트 관리에 관한 토론을 살펴볼 수 있습니다. 스마트포인터를 활용한 설계에 대한 질문 - weak_ptr 과 shared_ptr 의 사용에 대한 좋은 예시를 제공합니다. shared_ptr 질문 - shared_ptr 의 사용에 따른 메모리 관리에 대해 더 자세히 알 수 있습니다. 저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

[Service강의] owner -> shared_ptr