예를 들어 read() 시스템 콜을 호출한다고 하면 read()의 인자로 읽어올 문자수를 같이 넘겨줍니다. 즉, 어떤 파일로부터 얼마만큼의 문자를 읽어오라는 뜻이 되겠죠.
그런데 만약 읽어들일 파일에 더 적은 문자가 있는 경우 있는 문자까지만 읽어들이고 리턴할 수 있게 되어 있는 것이 non-blocking이고 정의된 문자수를 기다리고 있는 것(마치 pending된 것처럼 보이겠죠)이 blocking 모드입니다.
예를 들어 read() 시스템 콜을 호출한다고 하면 read()의 인자로 읽어올 문자수를 같이 넘겨줍니다. 즉, 어떤 파일로부터 얼마만큼의 문자를 읽어오라는 뜻이 되겠죠.
그런데 만약 읽어들일 파일에 더 적은 문자가 있는 경우 있는 문자까지만 읽어들이고 리턴할 수 있게 되어 있는 것이 non-blocking이고 정의된 문자수를 기다리고 있는 것(마치 pending된 것처럼 보이겠죠)이 blocking 모드입니다.
어느 것이 좋다고 할 수는 없습니다.
상황에 맞게끔 알맞게 쓰시면 됩니다.
약간의 오해의 소지가 있다고 생각합니다...
예를 드신 read()의 경우도 블럭킹 모드에서 읽기를 시도할 바이트보다 적더라도 리턴이 됩니다.
저는 blocking 을 좋아합니다. 가능하다면 block 되도록
driver를 작업합니다. application 이 1 tick 전체를 사용할
필요가 없는 경우가 대부분이고 busy waiting 또한 피해야
한다고 생각합니다. 의미없는 sleep,usleep 역시 사용하지
않는 것을 선호합니다. 이상 개인적인 의견이었습니다. ^^*
가능하면 비지 웨이팅은 피해야 하고, 보통은 디스크립터를 감시해서 준비가
되면 읽기를 시도하고(논 블러킹으로) 바로 리턴을 하는 식으로 해서 쓸데
없이 블럭이 되지도, 시피유를 소모하지도 않게 합니다.
newmania wrote:
저는 blocking 을 좋아합니다. 가능하다면 block 되도록
driver를 작업합니다. application 이 1 tick 전체를 사용할
필요가 없는 경우가 대부분이고 busy waiting 또한 피해야
한다고 생각합니다. 의미없는 sleep,usleep 역시 사용하지
않는 것을 선호합니다. 이상 개인적인 의견이었습니다. ^^*
블록 모드: scanf() 해보시면 터미널상에서 엔터를 칠 때까지 프로그램의 실행이 중지되어 있듯이, 데이터가 입력될 때까지 실행이 중단되는 방식을 말합니다.
논블록 모드는 더 이상 읽을 데이터가 없을 경우 데이터가 생길 때까지 기다리지 않고 바로 리턴하는 방식을 말합니다. 이때, 에러값을 리턴하지요. (EAGAIN 혹은 EWOULDBLOCK) 기본값(블록 모드)으로는 데이터가 없으면 생길 때까지 기다립니다.
그리고 블록 모드나 논블록 모드는 필요한 곳에 맞게 사용하면 됩니다. 쓰레드를 생각해봐도 단일 쓰레드냐 멀티 쓰레드냐 하는 것은 상황에 따라 더 적절한 방법이 따로 있다고 생각합니다. 많은 파일 디스크립터를 소수의 쓰레드로 처리할 때 논블록 모드가 필수적으로 필요할 수 있습니다.
블록 모드만 사용하는 것은 프로그램의 구조를 단순하게 유지하기에 좋고 그만큼 잘못된(비효율적인) 코드를 만들 가능성도 줄어듭니다. 따라서 블록 모드를 우선으로 고려하는 것이 바람직합니다. 그러나 많은 파일 디스크립터를 다룰 때 쓰레드나 프로세스도 많이 필요해지는 부담이 있겠지요.
busy waiting은 잘못된 코딩의 문제이지 블록/논블록의 문제는 아니라고 생각됩니다. sleep과 read(non-block)의 조합도 적당히 사용하면 시스템에 별 부담이 없습니다. 또한 게임 클라이언트와 같이 어차피 CPU 100% 쓰는 경우, 매번 select+read 할 바에는 바로 non-block read하는 게 더 효율적이기도 합니다.
예를 들어 read() 시스템 콜을 호출한다고 하면 read()의 인자로
예를 들어 read() 시스템 콜을 호출한다고 하면 read()의 인자로 읽어올 문자수를 같이 넘겨줍니다. 즉, 어떤 파일로부터 얼마만큼의 문자를 읽어오라는 뜻이 되겠죠.
그런데 만약 읽어들일 파일에 더 적은 문자가 있는 경우 있는 문자까지만 읽어들이고 리턴할 수 있게 되어 있는 것이 non-blocking이고 정의된 문자수를 기다리고 있는 것(마치 pending된 것처럼 보이겠죠)이 blocking 모드입니다.
어느 것이 좋다고 할 수는 없습니다.
상황에 맞게끔 알맞게 쓰시면 됩니다.
별은 바라보는 자에게 빛을 준다.
[quote="mooore"]예를 들어 read() 시스템 콜을 호출한다
약간의 오해의 소지가 있다고 생각합니다...
예를 드신 read()의 경우도 블럭킹 모드에서 읽기를 시도할 바이트보다 적더라도 리턴이 됩니다.
저는 blocking 을 좋아합니다. 가능하다면 block 되도록dr
저는 blocking 을 좋아합니다. 가능하다면 block 되도록
driver를 작업합니다. application 이 1 tick 전체를 사용할
필요가 없는 경우가 대부분이고 busy waiting 또한 피해야
한다고 생각합니다. 의미없는 sleep,usleep 역시 사용하지
않는 것을 선호합니다. 이상 개인적인 의견이었습니다. ^^*
가능하면 비지 웨이팅은 피해야 하고, 보통은 디스크립터를 감시해서 준비가
가능하면 비지 웨이팅은 피해야 하고, 보통은 디스크립터를 감시해서 준비가
되면 읽기를 시도하고(논 블러킹으로) 바로 리턴을 하는 식으로 해서 쓸데
없이 블럭이 되지도, 시피유를 소모하지도 않게 합니다.
블록 모드: scanf() 해보시면 터미널상에서 엔터를 칠 때까지 프로그
블록 모드: scanf() 해보시면 터미널상에서 엔터를 칠 때까지 프로그램의 실행이 중지되어 있듯이, 데이터가 입력될 때까지 실행이 중단되는 방식을 말합니다.
논블록 모드는 더 이상 읽을 데이터가 없을 경우 데이터가 생길 때까지 기다리지 않고 바로 리턴하는 방식을 말합니다. 이때, 에러값을 리턴하지요. (EAGAIN 혹은 EWOULDBLOCK) 기본값(블록 모드)으로는 데이터가 없으면 생길 때까지 기다립니다.
그리고 블록 모드나 논블록 모드는 필요한 곳에 맞게 사용하면 됩니다. 쓰레드를 생각해봐도 단일 쓰레드냐 멀티 쓰레드냐 하는 것은 상황에 따라 더 적절한 방법이 따로 있다고 생각합니다. 많은 파일 디스크립터를 소수의 쓰레드로 처리할 때 논블록 모드가 필수적으로 필요할 수 있습니다.
블록 모드만 사용하는 것은 프로그램의 구조를 단순하게 유지하기에 좋고 그만큼 잘못된(비효율적인) 코드를 만들 가능성도 줄어듭니다. 따라서 블록 모드를 우선으로 고려하는 것이 바람직합니다. 그러나 많은 파일 디스크립터를 다룰 때 쓰레드나 프로세스도 많이 필요해지는 부담이 있겠지요.
busy waiting은 잘못된 코딩의 문제이지 블록/논블록의 문제는 아니라고 생각됩니다. sleep과 read(non-block)의 조합도 적당히 사용하면 시스템에 별 부담이 없습니다. 또한 게임 클라이언트와 같이 어차피 CPU 100% 쓰는 경우, 매번 select+read 할 바에는 바로 non-block read하는 게 더 효율적이기도 합니다.
댓글 달기