답변:
실제로 시스템 호출에는 3 가지 그라데이션이 있습니다.
getpid, gettimeofday, getuid또는 setuid. 상황에 따라 일부 시스템 호출이 차단되거나 차단되지 않을 수 있습니다. 예를 들어 read, 파일이 비 블로킹 읽기를 지원하는 파이프 또는 다른 유형이고 O_NONBLOCK플래그 가 설정된 경우 차단하지 않습니다 .sleep입니다.read차단 파일 디스크립터 에서 호출되어 차단 중입니다 wait."빠른"시스템 호출과 "느린"시스템 호출의 차이점은 비 차단 vs. 차단에 가깝지만 이번에는 커널 구현 자의 관점에서 볼 때. 빠른 시스템 콜은 막거나 기다리지 않고 완료 할 수있는 것으로 알려져 있습니다. 커널이 빠른 syscall을 만나면 syscall을 즉시 실행하고 동일한 프로세스를 예약 된 상태로 유지할 수 있다는 것을 알게됩니다. ( 비 선점 형 멀티 태스킹 이있는 일부 운영 체제 에서는 빠른 시스템 콜이 선점 형이 아닐 수 있습니다. 일반적인 유닉스 시스템에서는 그렇지 않습니다.) 반면에 느린 시스템 콜은 다른 작업이 완료 될 때까지 기다려야합니다. 따라서 커널 호출 프로세스를 일시 정지하고 다른 태스크를 실행할 준비를해야합니다.
어떤 경우는 약간 회색 영역입니다. 예를 들어, read일반 파일에서 읽은 디스크 는 일반적으로 다른 프로세스를 기다리지 않기 때문에 비 블로킹으로 간주됩니다. 디스크를 기다리는 것입니다. 일반적으로 응답하는 데 약간의 시간이 걸리지 만 영원히 걸리지 않습니다 (따라서 위의 경우 2). 그러나 커널의 관점에서 볼 때 프로세스는 디스크 드라이버가 완료 될 때까지 기다려야하므로 시스템 호출이 느립니다.
O_NONBLOCK플래그 상태에 따라 둘 다 가질 수 있습니다 . 플래그가 설정되면 syscall은 다른 것을 기다리지 않고 완료 될 수 있으므로 차단되지 않으며 커널은이를 빠른 syscall로 처리 할 수 있습니다.
느린 시스템 호출은 TCP 소켓 read ()와 같습니다. O_ASYNC (또는 무엇이든)가 설정되어 있지 않으면 기다릴 수 있습니다.
빠른 시스템 호출은 gettimeofday () 또는 getpid ()와 비슷합니다. 둘 다 커널이 즉시 사용할 수있는 프로세스로 정보를 반환합니다.
디스크 읽기는 느린 시스템 호출 범주에 속합니다. 프로세스가 실제 디스크 파일 인 파일 디스크립터에서 read ()를 수행하는 경우, 커널은 읽기를 만족시키기 위해 하나 이상의 디스크 블록을 읽어야 할 수도 있습니다. 기본 파일 시스템의 디스크 내 구조에 따라, 이것은 "indirect block"의 디스크 블록 번호를 얻기 위해 온 디스크 -inode를 읽고, 데이터 블록을 얻기 위해 간접 블록을 읽은 다음 데이터 블록 자체를 읽는 것을 의미 할 수 있습니다. . 적어도 디스크 액세스 당 CPU주기와 관련하여 상당한 시간이 소요될 수 있습니다. 아마도 Good Old Days보다 더 나쁠 것입니다.
나는 이것을 오랫동안 보지 못했지만, 오래된 유닉스 디스크 드라이브 장치 드라이버 코드의 "하단"은 신호 / 인터럽트를 차단하여 디스크상의 파일 시스템 무결성을 유지하는 것이 더 쉬웠습니다. 때때로, 버그가있는 드라이버 나 고장난 디스크는 프로세스가 요청한 디스크 블록을 전달하지 않았으며 프로세스가 영원히 잠들었습니다. 살인 -9조차도 아무것도하지 않았습니다.