가변 길이 자료구조 vs OPEN_MAX를 활용한 배열

• 과제 get_next_line의 풀이에 대해 작은 논란이 있다.
• 이 논란은 가변 길이의 자료구조와, OPEN_MAX 값을 활용한 배열을 통해 풀이하는 두 방법 중 어떤 것이 옳은 것인가? 라는 질문에서 시작된다.
• 필자의 경우 linked list를 활용한 풀이와 OPEN_MAX를 활용한 풀이를 모두 구현했다. 그러나 결과적으로는 OPEN_MAX로 풀이하는 것이 올바른 풀이라고 생각하여 OPEN_MAX를 통한 풀이로 제출하였다.
• 해당 글은 필자는 왜 OPEN_MAX를 활용한 배열을 통해 풀이를 하였는 지에 대해서 작성하였다.

우선, 해당 논란에서 가변길이의 자료구조를 활용해야한다는 의견의 주장은 OPEN_MAX에서부터 시작된다.

OPEN_MAX를 통한 풀이의 문제

OPEN_MAX는 Linux에서 정의되어 있지 않다.

• OPEN_MAX 값을 활용하게 될 경우, “limits.h” 에 정의되어있는 OPEN_MAX 값을 활용하게 된다.
• 그러나 limits.h 에서 OPEN_MAX가 정의되지 않은 운영체제가 존재한다.
• 따라서 함수를 정의하며 임의로 OPEN_MAX 값을 정의해야한다.

  • 이 경우에는 헤더에 임의로 정의해둔 OPEN_MAX 값을 활용하게 된다.

  • 필자의 경우, 이 임의의 OPEN_MAX 값으로서 클러스터 맥에서 제한되어있는 file descriptor 의 한계값이었던 4만 이상으로 설정하였다. (별도로 테스트 코드를 만들어 돌려 ulimit 을 통해 해제를 하더라도 약 4만 개 이상의 파일은 더 이상 열리지 않음을 확인했다.)

    

  • m1 macbook air 환경에서는 file descriptors를 90000으로 해제하더라도 10240개 이상 열리지 않는다.

  • 따라서 각 운영체제마다 설정된 최대 file descriptors 개수가 정해진 것으로 추측된다. (ulimit와 별도로...)

  • 테스트에 활용한 코드

OPEN_MAX를 통해서는 파일을 모두 열지 못할 수도 있다.

• 앞서 OPEN_MAX 에 대해서 잠시 살펴보았듯이, OPEN_MAX 값은 항상 운영체제에서 설정된 file descriptors 값과 같다는 보장이 없다.
  • limits.h 에 지정된 값의 경우 10,240이었지만, 실제로는 10,240보다 더 큰 값까지 한계를 설정할 수 있었다.
  • 10,240개 이상의 파일을 열려고 할 경우 해당 함수는 오류를 발생할 것이다.
• 이러한 이유로 인해서 OPEN_MAX를 통한 풀이는 적절하지 않다.

따라서 위와 같은 논리를 통해서 OPEN_MAX 를 이용한 풀이는 다소 적절하지 못하다고 주장할 수 있다.

그러나, 나는 위와 같은 문제를 인지하고 있음에도 OPEN_MAX를 통해 풀이하였다. 이를 설명하기 위해서 가변길이 자료구조의 문제를 서술해보고자한다.