정오표 : 리눅스 시스템 네트워크 프로그래밍 (2판)

Advanced 리눅스 시스템 네트워크 프로그래밍 오탈자 정오표

(최근 업데이트 목록은 맨 아래의 history를 참고해 주시기 바랍니다.)

* p.126 3번째 문단

수정전	수정후
posix_madvise는 addr부터 len까지의 메모리 공간에 대해 ...생략... advise에 사용 가능한 힌트는 표 4.5에 정리해보았다.	posix_madvise는 addr부터 len까지의 메모리 공간에 대해 ...생략... advise에 사용 가능한 힌트는 표 5.5에 정리해보았다.

* p.156 4번째 문단

수정전	수정후
이 기능은 기존 세마포어와는 역으로 작동하여 세마포어 값이 0이면 깨어나고 양수면 잠복하게 된다. 이런 다양한 기능 덕분에 ISI 세마포어는 아직도 많이 사용되는 기능이다.	이 기능은 기존 세마포어와는 역으로 작동하여 세마포어 값이 0이면 깨어나고 양수면 잠복하게 된다. 이런 다양한 기능 덕분에 XSI 세마포어는 아직도 많이 사용되는 기능이다.

* p.108 그림, p109 본문

수정전	수정후
그림이 "그림 3.2"로 잘못 표기됨	"그림 4.1" 이 맞는 표기임
109페이지의 "그림 3.2"의 표기는 모두 잘못된 표기	"그림 4.1" 이 맞는 표기임

* p.180 코드 5.23. 1번행 오타

수정전	수정후
01 struct timespect  ts_timeout;  02 ts_timeout.tv_sec = time(NULL) + 10;	01 struct timespec  ts_timeout;  02 ts_timeout.tv_sec = time(NULL) + 10;

* p.184 4번째 문단

수정전	수정후
그렇다면 이번에는 터미널을 2개를 열고 예제를 동시에 2개 실행시키면 어떻게 될까? 당연히 먼저 실행된 예제는 그림 5.17처럼 생성하면서 진행되겠지만, 두번째 실행된 예제는 연결(attach)만 했다는 메시지가 나오고 진행될 것이다.	앞서 posix_named_sem_cnt를 실행시키면 교착상태에 빠지기 때문에 교착 상태를 해결하는 프로그램이 필요해진다. 이 프로그램에는 명명된 세마포어의 이름을 입력하면, 이를 제거하거나 sem_post로 세마포어 값을 증가시키는 기능이 있어야 한다. 이는 여러분의 숙제로 남겨두겠다.  그러면 이제 교착상태에 빠지지 않도록 코드 5.24의 55번 행을 제거하여 정상 작동 시켜보자. 정상 작동시 서로 다른 프로세스가 세마포어를 공유하는지 확인도 해봐야 한다.  그렇다면 이번에는 터미널을 2개를 열고 예제를 동시에 2개 실행시키면 어떻게 될까? 당연히 먼저 실행된 예제는 그림 5.17처럼 생성하면서 진행되겠지만, 두번째 실행된 예제는 연결(attach)만 했다는 메시지가 나오고 진행될 것이다.

* p.202 코드 5.35

수정전	struct  mq_attr {   long int mq_flags;    /* 메시지 큐 플래그 (O_NONBLOCK)  */   long int mq_maxmsg;   /* 메시지 큐의 최대 메시지 개수 제한  */   long int mq_msgsize;  /* 메시지 큐의 최대 용량 바이트 (메시지의 총합은 이 값을 넘을 수 없다) */   long int mq_curmsgs;  /* 현재 큐에 저장된 메시지 개수  */ };
수정후	struct  mq_attr {   long int mq_flags;    /* 메시지 큐 플래그 (O_NONBLOCK)  */   long int mq_maxmsg;   /* 메시지 큐의 최대 메시지 개수 제한  */   long int mq_msgsize;  /* 메시지 1개의 최대 용량 바이트 */   long int mq_curmsgs;  /* 현재 큐에 저장된 메시지 개수  */ };

* p.202 제일 아래 문단

수정전	수정후
POSIX 메시지 큐는 메시지 1개의 크기는 제한하지 않으며 다만 모든 메시지의 총합이 최대 용량만 넘지 않으면 된다.	((삭제 - 틀린 내용임))

* p.250 그림 6.6

수정전	수정후
그림 6.6에서 Server side에 accept()가 빠져있음	수정된 그림은 아래와 같음

그림 6.6 TCP 소켓 관련 함수와 TCP 상태 전이

* p.274 표 6.17

수정전	수정후
[표 6.17] TCP 헤더의 제어 플래그	[표 6.17] TCP와 UDP의 차이

* p.441 아래에서 2번째 문단

수정전	수정후
이 때 pthread_barrier_wait의 리턴값은 오직 하나의 쓰레드만 PTHREAD_BARRIER_SERIAL_THREAD를 받고 나머지는 0을 리턴하게 된다. 따라서 깨어나면서 한 번만 실행되어야 하는 재초기화 작업이 있다면 PTHREAD_BARRIER_SERIAL_THREAD를 리턴받은 쓰레드가 실행하도록 하면 된다. 한 번 사용된 배리어는 초기화를 통해 다시 사용할 수 있다.	이 때 pthread_barrier_wait의 리턴값은 오직 하나의 쓰레드만 PTHREAD_BARRIER_SERIAL_THREAD를 받고 나머지는 0을 리턴하게 된다. 따라서 깨어나면서 한 번만 실행되어야 하는 재초기화 작업이 있다면 PTHREAD_BARRIER_SERIAL_THREAD를 리턴받은 쓰레드가 실행하도록 하면 된다. 한 번 사용된 배리어는 pthread_barrier_destroty로 파괴한 뒤에 초기화를 통해 다시 사용할 수 있다.

* p.606 [코드 10.16] AIO 리스트 작업 처리

수정전 (바로 아래)

AIO 예제 aio_listio.c - 버그 수정전

수정후 (바로 아래)

AIO 예제 aio_listio.c - 버그 수정후

** p.606 참고 설명 :

Bug 1. 논리적 구조 버그

루프문 내에서 i 인덱스와 tot_len을 계산하는 부분의 논리적 순서에 버그가 있었습니다. 따라서 계산하는 코드의 위치를 변경하였습니다.

Bug 2. 기술적인 버그

두 예제 모두 lio가 모두 처리되기 전에 다른 lio가 진행되어 lio 함수내에서 사용되는 aiocb 블록이 훼손될 수 있는 문제가 있습니다. 이를 해결하기 위해 다음과 같이 작성했습니다.

SIGEV_THREAD를 사용하는 aio_listio.c 에서는 pthread barrier를 설치하여 5개의 list AIO마다 동기화를 진행하도록 하였습니다.

SIGEV_SIGNAL을 사용하는 aio_list_sig.c에서는 signal을 받을 때까지 pause 시키도록 하여 5개의 list AIO마다 동기화를 진행하도록 하였습니다. pause 대신에 sigsuspend를 사용하는 편이 좋으나, 코드가 지저분해지므로 그냥 pause를 사용하도록 했습니다.

---

리눅스 시스템 네트워크 프로그래밍

---

* 히스토리

2014.11.04 p.180 코드 5.23 1번행

2014.08.17 p.606 코드 10.16 (배포되는 예제 코드 참조) : aio_listio.c aio_listio_sig.c 버그 수정

2014.08.17 p.441 아레에서 2번째 문단

2013.09.14 p.202 코드 5.35, 제일 아래 문단

2013.09.10 p.157 표 5.14 (semcnt), p202 코드 5.35, 제일 아래 문단

2013.09.07 p.108~109 그림, p184 4번째 문단.

2013.06.15 p.250 그림 6.6

2013.03.13 p.126 3번째 문단, p156 4번째 문단

2012.10.29 p.274 표 6.17