우연히 제 이야기가 거론되는것을 들었습니다.
네. 맞습니다. OPEN_MAX를 활용한 정적배열을 사용하여 통과했을 직접 밝혔습니다.
저는 당시에 파일 오픈 최대값을 의미하는 OPEN_MAX를 무조건 알 수 있고, 이를 활용한 코드가 올바르다고 오해하고 있었습니다. 그래서 오히려 리스트를 사용하는것에 거부감을 가지고 있었습니다.
그때 읽어들인 스트링을 합치는 과정에서 리스트를 활용하면 나름의 이점이 있다는 것을 듣게 되었고, 저는 보너스에서 FD쪽은 OPEN_MAX를 활용한 정적배열을 사용하고, 스트링을 합치는 과정을 리스트를 활용하여 구현했습니다.
그리고 추가로 이슈 제기전, 주말과 월요일 당일을 활용해 FD쪽을 리스트로 구현하는 코드를 작성했고, 테스터기까지 통과함을 확인했습니다. 결코 ‘난 OPEN_MAX로 통과했지만, 너흰 안돼.’ 라는 식의 이슈 제기가 아니였음을 말씀드리고 싶습니다.
저는 과제를 통해 올바른 고민을 많이 할 수 있기를 바라고 있습니다. 그래서 제가 제기한 것이 ‘OPEN_MAX를 활용한 배열은 무조건 틀리게 하자’가 아니라, ‘OPEN_MAX 관련하여 시스템 한도에 대해 고찰해보는 것도 굉장히 유용하니, 이것을 유도하자’ 였던 것입니다.
sungjpar 님의 GNL OPEN_MAX vs Linked list? 포스팅을 읽었습니다. 한 번 디펜스를 펼쳐보겠습니다.
참고로 sungjpar님처럼 OPEN_MAX에 대해 고찰을 가져봤던 사람에게는 PASS 기꺼이 주는것도 나쁘지 않을까가 저의 의견입니다.
별도로 테스트 코드를 만들어 돌려 ulimit 을 통해 해제를 하더라도 약
4만 개 이상의 파일은 더 이상 열리지 않음을 확인했다
저는 클러스터의 맥 환경에서 너끈히 4만개 이상의 FD가 열리는 것을 확인했습니다.
m1 macbook air 환경에서는 file descriptors를 90000으로 해제하더라도 10240개 이상 열리지 않는다.
앞서 클러스터의 Mac 환경에서는 4만개 이상의 fd가 열림을 확인했습니다. 또한 작동 환경에 따라서 변화하는 값에 의존하는것은 잘 못된 선택이라고 봅니다. 그리고 파일을 OPEN_MAX까지 직접 open하지 않더라도 dup2()를 통해 fd값을 높게 설정하는 것은 아주 쉽게 가능합니다. (pipex를 선택하시면, 사용할 함수입니다.)
