스레드가있는 클라이언트/서버 프로그램을 작성하려고합니다. 연결이 끝나면 소켓을 닫습니다. 서버는 새로운 연결을 많이 얻었고 소켓 번호 (파일 디스크립터)는 매우 빠르게 증가했다. 5 분 후에 나는 이미 파일 디스크립터 번호 800 주위에 있었다!클로저 소켓 문제
정상적인 현상입니까? 스레드가 파일 설명자를 공유합니까? close(sockfd);은 immediatly 또는 잠시 후에 출시 된 번호입니까?
추신 : 저는 fork()와 관련이있었습니다.이 문제는 없었습니다. 감사
pthreads(7)에서
파일 설명자 a 모든 스레드간에 공유되므로 한 스레드에서 닫으면 다른 모든 스레드에서 닫힙니다.
가까이의 반환 값을 확인하지 공통 그럼에도 불구하고 심각한 프로그래밍 오류는 다음과 같습니다 가까운하지만 오류를 반환 할 수있는 호출이 반환 (오류가 발생하지 않는 한)
주 때) (닫기는 FD 출시 . 이전의 write (2) 작업에서의 오류가 최종 닫을 때 처음보고되는 것은 가능합니다. 파일을 닫을 때 값을 확인하지 않으면 데이터가 자동으로 손실 될 수 있습니다. 이것은 특히 NFS 및 디스크 할당량에서 볼 수 있습니다.
소켓보다 다른 파일 설명자 사용을 확인하십시오. 다른 곳에서 fds를 유출 한 것일 수 있습니다. 예 : 일반 파일을 여는 경우
:
POSIX.1는 스레드가 다른 속성의 범위를 공유해야합니다 (즉, 이러한 특성은 공정 전체가 아닌 당 스레드 수 있습니다) :
- 열린 파일 설명자
이 문제는 실제로 발생합니까? 코드가 작동하지 않습니까? 왜 구현 정의 된 숫자에 관심이 있습니까? 당신의 시스템이 파일 디스크립터를 무작위로 할당하고 파일 디스크립터로 123456789를 주었다면 어떻게 할 것입니까? –
@Adrien Plisson filedescriptors는 사용 가능한 가장 낮은 번호를 사용하도록 보장되기 때문에. 이것은 그가 800이라는 값으로 새로운 fds를 얻는다면, 그는 800 fds를 열어 자원 누출을 나타낼 가능성이 있다는 것을 의미합니다. 이것은 나쁜 것입니다. fd 번호는 또한 비트 세트에 직접 매핑된다. select() 세트와 그 비트 수는 유한입니다. 따라서 실제 값이 중요합니다. – nos
어떤 운영 체제입니까? 리눅스를 사용한다면'/ proc//fd /'를 보면이 파일 디스크립터가 무엇을 참조하는지 알 수 있습니다. –
caf