참 놀라운 세상

출처 : http://sthyun.tistory.com/entry/EWOULDBLOCKEAGAIN

---------------------------------------------------------------------------------

넌블럭킹 소켓

socket() 으로 생성되는 소켓은 기본값으로 Blocking 소켓이다. 하지만 이미 생성된 소켓을 fcntl() 함수를 사용하여 nonblocking socket으로 변경 가능하다.

※ Blocking Socket(B)/Nonblocking Socket(N)

(여기서 errno는 errno.h를 인클루드해야 이용할수 있다.)

- read

• B : read 버퍼가 비어있을때 block
• N : read 버퍼가 비어있을때 -1 return, errno==EWOULDBLOCK/EAGAIN

* Blocking socket의 경우에 read 버퍼에 존재하는 데이터의 크기가 read시 요청한 데이터의 크기보다 작은 경우라도 read 버퍼에 존재하는 데이터만큼 리턴되며 block 되지 않음.

- write

• B : write 버퍼가 꽉 차있을때 block
• N : write 버퍼가 꽉 차있을때 -1 return, errno==EWOULDBLOCK/EAGAIN

- accept

• B : backlog( 현재의 connection 요청 큐 )가 비어있을때 block
• N : backlog( 현재의 connection 요청 큐 )가 비어있을때 -1 return, errno==EWOULDBLOCK/EAGAIN

- connect

• B : connection이 완전히 이루어질때까지 block
• N : connection이 완전히 이루어지 않더라도 곧바로 return. 나중에 getsockopt로 connection이 완전히 이루어졌는지 확인가능.

※ Nonblocking 소켓의 장점/단점

• 장점 : 멀티스레드를 사용하지 않고도 다른 작업을 할 수 있다.
• 단점 : 프로그램이 복잡해지며, CPU 사용량이 증가한다.
• 멀티쓰레드 기반에서 nonblock socket 을 사용하면 cpu 사용량이 엄청나게 증가한다.
  이건 성능상의 차이는 확연한데 gprof 를 돌려도 안나온다. 멀티쓰레드 환경에서는 절대 사용하지말것.

※ Nonblocking 소켓으로 만드는 방법 : fcntl()함수를 이용한다.

int flag;

flag = fcntl( sock_fd, F_GETFL, 0 );

fcntl( sock_fd, F_SETFL, flag | O_NONBLOCK );

파일 입력과 출력
이 절은 파일 기술자상의 기본 입력과 출력 명령을 수행하기 위한 함수들을 설명하고 있다:

read, write, 그리고 lseek. 이들 함수들은 헤더파일 'unistd. h'에 선언되어 있다.

read함수는 기술자 filedes의 파일로부터 size 바이트를 읽고, 그 결과를 버퍼에 저장한다. (이것은 문자 스트링이 필요하지 않고 그곳에는 부가된 널 종료문자가 없다)

ssize_t read (int filedes, void *buffer, size_t size)

반환 값은 실제로 읽은 바이트의 수이다.

이것은 size보다 적을수도 있다

예를 들어, 만일 파일에 남겨진 바이트의 수가 적거나 즉시 유용한 바이트의 수가 적은 경우 등이 있다.

정확한 동작은 파일의 종류가 무엇인지에 따라 의존한다.

size 바이트보다 덜 읽는 것은 에러가 아님을 기억하라.

0의 값은 파일의 끝을 지적한다. ( 만일 size 인수의 값이 0인 경우를 제외하고. . ) 이것은 에러로 간주하지 않는다.

만일 당신이 파일의 끝인 상태에서 read를 호출하면, 그것은 0을 반환하는 것 외에 아무 일도 하지 않는다.

만일 read가 적어도 한 문자를 반환한다면, 당신이 파일의 끝에 도달했는지를 알 수 있는 아무런 방법이 없다.

그러나 만일 당신이 끝에 도달해 있었다면 다음 read의 호출은 0을 반환해서 파일의 끝임을 지적해줄 것이다.

에러가 발생한 경우에, read는 -1을 반환한다.

다음의 errno는 이 함수에서 정의된 에러의 상황이다.

EAGAIN 일반적으로, 즉시 유용한 입력이 없을 때, read는 입력을 기다린다.

그러나 만일 그 파일에서 O_NONBLOCK가 설정되면 read는 아무런 데이터도 기다리지 않고 즉시 반환하고, 이 에러를 보고한다.

호환성 노트 : BSD Unix의 대부분의 버전은 이것을 위한 다른 에러코드를 사용한다:

EWOULDBLOCK. GNU 라이브러리에서는, EWOULDBLOCK은 EAGAIN의 다른 이름이다. 그래서 당신이 어떤 이름을 사용해도 문제가 발생되지 않는다.

어떤 시스템들은, 특별한 문자 파일로부터 데이터의 큰 덩어리를 읽으려 할 때, 만일 커널(kernal)이 당신의 것을 담을 수 있는(to lock down the user's pages), 충분한 물리적 메모리를 얻을 수 없는 경우에 EAGAIN의 에러를 내고 실패했음을 지적한다.

디바이스가 사용자의 메모리 영역을 직접적으로 억세스 하는 것이 제한되어 있는 것은 그들은 커널내부의 분리된 버퍼를 사용하기 때문이다. 그것에 터미널들은 포함되지 않는다,

EBADF 

filedes 인수에 주어진 것이 유용한 파일 기술자가 아니다.

EINTR 

read가 입력을 기다리고 있는 동안 시그널에 의해 인터럽트 되어졌다.

EIO 

많은 디바이스들, 그리고 디스크 파일들을 위하여, 이 에러는 하드웨어 에러를 지적한다.

EIO는 또한 제어 중인 터미널로부터 배경 프로세스가 읽기를 시도하고, SIGTTIN의 신호가 아무런 동작도 하지 않고 보내짐에 의해 멈춘 프로세스의 일반적 동작에 대해 발생한다.

이것은 만약 신호가 블록되어지거나 무시되거나, 프로세스 그룹이 부모 프로세스를 잃어 버렸다면 발생되어질 것이다.

ssize_t write (int filedes, const void *buffer, size_t size)

write함수는 기술자 filedes 파일에 버퍼에 있는 size 바이트의 데이터를 쓰는 함수이다. 버퍼에 있는 데이터는 문자 스트링과 널 문자가 필요하지 않다. 반환 값은 실제로 쓰여진 바이트들의 개수이다.이것은 보통은 size와 같지만, 더 적을수도 있다 ( 예를 들어, 만일 물리적 매체가 채워져 있는 경우 ). 에러가 발생하면 write는 -1을 반환한다.

다음의 errno는 이 함수에서 정의한 에러상황이다.

EAGAIN 

일반적으로 write 명령하에서 블록 쓰기 동작은 완벽하다.

그러나 만일 그 파일에서 O_NONBLOCK 플래그가 설정되어 있다면, 그것은 어떤 데이터도 쓰지 않고 곧바로 반환하고, 에러를 발생한다.

그 상황에 대한 하나의 예는 프로세스가 출력하려는 블록을 STOP 문자를 받아들임으로 인해 출력이 일시 중단되고, 흐름제어를 지원하는 터미널 디바이스에 쓰기를 시도할 때 발생한다.

EWOULDBLOCK. 

GNU 라이브러리에서는, EWOULDBLOCK은 EAGAIN의 다른 이름이다.

그래서 당신이 어떤 이름을 사용해도 문제가 발생되지 않는다.

어떤 시스템들은, 특별한 문자 파일로부터 데이터의 큰 덩어리를 쓰려 할 때, 만일 커널(kernal)이 당신의 것을 담을 수 있는( to lock down the user's pages ), 충분한 물리적 메모리를 얻을 수 없는 경우에 EAGAIN의 에러를 내고 실패했음을 지적한다.

디바이스가 사용자의 메모리 영역을 직접적으로 억세스 하는 것이 제한되어 있는 것은 그들은 커널내부의 분리된 버퍼를 사용하기 때문이다. 그것에 터미널들은 포함되지 않는다,

EBADF 

filedes 인수는 유용한 파일 기술자가 아니다.

EFBIG 

파일의 크기가 그 실행에서 지원할 수 있는 것보다 크다.

EINTR 

write 오퍼레이션은 명령이 완전히 수행될 때까지 기다리는 동안 신호에 의해 인터럽트 되어졌다.

EIO 많은 디바이스들, 그리고 디스크 파일들을 위하여, 이 에러는 하드웨어 에러를 지적한다.

EIO는 또한 제어 중인 터미널로부터 배경 프로세스가 읽기를 시도하고, SIGTTIN의 신호가 아무런 동작도 하지 않고 보내짐에 의해 멈춘 프로세스의 일반적 동작에 대해 발생한다.

이것은 만약 신호가 블록되어지거나 무시되거나, 프로세스 그룹이 부모 프로세스를 잃어 버렸다면 발생되어질 것이다. ENOSPC 디바이스가 차 있다.

EPIPE

이 에러는 어느 프로세스에 의해서 읽기 위해 개방되지 않는 파이프나 FIFO에 쓰려 시도할 때 반환된다.

이것이 발생될 때, SIGPIPE 신호를 프로세스에 보낸다.

당신이 EINTR 실패를 방지하기 위해 조정하지 않았다면, 당신은 실패한 write의 호출에 대해서 errno를 체크해야할 것이다. 그리고 만일 errno가 EINTR 이라면, 그냥 간단하게 다시 호출해주면 된다.

이것을 하는 쉬운 방법으로 매크로 TEMP_FAILURE_RETRY 가 있다. 다음처럼:

nbytes = TEMP_FAILURE_RETRY (write (desc, buffer, ount));

write 함수는 fputc처럼 스트림에 쓰는 모든 함수들에 기본적으로 포함되어 있다. 

출처 : http://kuaaan.tistory.com/trackback/142

delete와 delete[], new와 new[]를 구분해서 사용해야 하는 이유 :

delete를 사용하든 delete[]를 사용하든 메모리는 정상적으로 해제된다. 하지만 4바이트 INT 타입의 10개짜리 Array를 메모리해제할 경우 delete[]를 사용하면 4바이트씩 10번 해제하지만 delete를 사용하면 40바이트짜리 메모리를 한번 해제한다. 

new 실패에 따른 프로세스 종료원인을 찾다가 좋은 정보를 찾았습니다.

블로깅...

출처 : http://kuaaan.tistory.com/123

동적 메모리를 다음과 같이 사용하였습니다. 어디가 틀렸을까요?

LPINT lpInt = NULL; lpInt = (LPINT)malloc(sizeof(INT)); *lpInt = 4; printf("Value : %d\r\n", *lpInt); free(lpInt); LPINT lpInt = NULL; lpInt = (LPINT)malloc(sizeof(INT)); if (lpInt == NULL) { printf("Fail to alloc memory!!\r\n"); return FALSE; } *lpInt = 4; printf("Value : %d\r\n", *lpInt); free(lpInt); LPINT lpInt = NULL; INT nTotalBytes = 0, nAllocByte = 10000000; while(TRUE) { lpInt = NULL; lpInt = new INT[nAllocByte]; nTotalBytes += nAllocByte * sizeof(INT); if (lpInt == NULL) { printf("Fail to alloc memory!!\r\n"); break; } printf("Alloc Success!! (%d)\r\n", nTotalBytes); } // blah~ blah~ 말하자면, new 연산자가 메모리 할당에 실패했을 경우, C++ 스탠다드에 따라 std::bad_alloc Exception을 throw한다는 의미입니다. exception이 throw되었기 때문에 넘겨받은 포인터가 NULL인지 체크하는 부분까지 진행되지도 않고 프로그램이 종료된 것입니다.

음. 그렇다면 다음과 같이 코딩하면 메모리 할당 예외처리가 가능하겠군요.

view plaincopy to clipboardprint?

1. try  
2. {  
3.     LPINT   lpInt = NULL;  
4.     INT nTotalBytes = 0, nAllocByte = 10000000;  
5.   
6.     while(TRUE)  
7.     {         
8.         lpInt = NULL;  
9.   
10.         lpInt = new INT[nAllocByte];  
11.         nTotalBytes += nAllocByte * sizeof(INT);  
12.   
13.         printf("Alloc Success!! (%d)\r\n", nTotalBytes);  
14.     }  
15. }  
16. catch ( exception e )  
17. {  
18.     printf("%s\r\n", e.what( ));  
19. }  

try { LPINT lpInt = NULL; INT nTotalBytes = 0, nAllocByte = 10000000; while(TRUE) { lpInt = NULL; lpInt = new INT[nAllocByte]; nTotalBytes += nAllocByte * sizeof(INT); printf("Alloc Success!! (%d)\r\n", nTotalBytes); } } catch ( exception e ) { printf("%s\r\n", e.what( )); }

코드를 위와 같이 수정하고 실행시키면 다음과 같이 동작하게 됩니다.

종료되기 직전 부분을 보면 제대로 Exception Handling이 되었다는 것을 알 수 있습니다.

그런데, 동적메모리 할당할 때마다 이와 같이 try ~ catch를 해주려면 너무 귀찮죠. 성능 문제로 try ~ catch를 사용하시지 않는 경우도 있구요. 더 좋은 방법은 "new handler"를 등록해주는 것입니다.

MSDN을 좀 더 검색해보면 "new handler"에 관한 내용이 나와 있습니다.

If the attempt is successful, the function returns a pointer to the allocated storage. Otherwise, the function calls the designated new handler. If the called function returns, the loop repeats. The loop terminates when an attempt to allocate the requested storage is successful or when a called function does not return.

The required behavior of a new handler is to perform one of the following operations:

• Make more storage available for allocation and then return.

• Call either abort or exit(int).

• Throw an object of type bad_alloc.

The default behavior of a new handler is to throw an object of type bad_alloc. A null pointer designates the default new handler.

The order and contiguity of storage allocated by successive calls to operator new(size_t) is unspecified, as are the initial values stored there.

위의 내용을 요약해보면 다음과 같습니다.

1. new 연산자가 메모리 할당에 실패한 경우 "new handler"로 지정된 함수가 호출된다. 이 함수가 리턴한 다음에 메모리 할당이 실패한 시점부터 계속 실행된다.

2. "new handler" 는 다음의 세가지 작업 중 한가지를 수행해야 합니다.

1) 메모리를 확보한 후 return한다.

2) 프로세스를 종료시킨다.

3) bad_alloc 을 throw한다.

3. Default "New Handler"는 bad_alloc 을 throw 한다.

음, new 연산자가 메모리 할당에 실패했을 때 bad_alloc이라는 exception이 throw 되는데, 이것은 사실은 Default로 등록된 "new handler"에서 하는 일이라는 것을 알 수 있네요.

그렇다면, 이 내가 원하는 함수를 "new handler"로 등록하려면 어떻게 해야 할까요??

new_handler set_new_handler(
   new_handler _Pnew
) throw( );

출처 : http://no1rogue.blog.me/30097158983

* 메모리 맵 - mmap() <파일 혹은 디바이스를 메모리와 대응>

; 파일(리눅스에서는 디바이스도 파일로 처리하므로 디바이스도 메모리 맵으로 연결 가능)을 처리하기 위해서는 보통 저수준으로는 파일 디스크립터를 이용하고, 고수준으로 접근하기 위해서는 파일 구조체 포인터를 이용하여 접근하게 된다. 하지만 이런 방식을 이용하면 버퍼를 거쳐서 실제 입출력을 하게된다. 하지만 mmap()을 이용하여 메모리 맵 방식으로 파일을 연결하게 되면 버퍼를 이용하는 것이 아니라 '페이지(page)'를 이용하여 데이터 처리가 가능해진다. 상대적으로 크기가 작은 버퍼에 비해 보통 4KB의 크기를 가지는 페이지를 이용하면 처리 가능한 크기와 처리 속도가 향상된다. 그렇기 때문에 데이터 크기가 크거나 빠른 처리를 해야하는 경우 메모리 맵 방식을 종종 사용하게된다. 메모리 맵을 사용하면 처리 속도가 빨라지는 예가 바로 처리하는 데이터가 큰 동영상을 볼 때이다. 그리고 실제 실행 파일도 윈도우든 리눅스든 실행 할 때 페이지로 분할되므로 메모리 맵 방식으로 매핑된다. 대표적으로 코드 영역은 데이터의 변경이 없기 때문에 메모리 맵을 이용해 맵핑하면 처리 속도는 물론이고 메모리 낭비도 없다. 

* 특징

1. 생성된 메모리 맵을 포인터를 이용하여 쉽게 사용 가능하다.

2. 파일로 연결하여 사용시 메모리-파일 사이의 동기화가 편하다.

3. IPC(프로세스간 통신)로 활용 가능하다.

4. 대용량의 데이터를 사용할 시 성능이 향상된다.

* 주의점

- 메모리 맵은 바로 파일의 처리하는게 아니라 가상 메모리로 활용되는 페이지에 맵핑하는 방식이다. 그러므로 파일과 해당 메모리 맵이 된 페이지가 다른 공간이다. 그러므로 커널에 의해 여유 시간에 동기화(둘의 데이터가 같아지는..)가 될 때까지 서로 다른 데이터를 가질 수 있다. 그러므로 동기화에 대한 주의를 할 필요가 있다. <개발자가 직접 커널에 동기화를 명령 할 수 있는 함수도 있다. - fsync()>

 IPC로 사용 할 때에도 프로세스간 동기화에 대한 주의도 필요하다.

* 2가지 방식

1. 공유 메모리 맵 방식 (Shred Memory-Map)

; 메모리 맵 변경 시 원본 파일과 데이터가 동기화가 되는 방식

2. 복사 메모리 맵 방식 (Private Memory-Map)

; 처음 메모리 맵에 매핑 될때 파일의 내용을 읽어와서 복사하고 그 이후 동기화 하지 않는 방식.

* 메모리 맵 생성 함수 - mmap()

void* mmap(void *state, size_t length, int prot, int flags, int fd, ott_t offset);

- void *state

; 할당받기 원하는 메모리 주소. 보통 0을 써서 커널이 적합한 공간을 임의로 할당해 주소를 받을 수 있고, 직접 입력하여 사용해도된다. 하지만 직접 입력하는 경우 해당 시스템의 페이지 (배수)단위로 주소 값을 설정해줘야 한다.

- size_t length

; 메모리 맵을 할 크기. 바이트 단위로 설정한다.

- int prot

; 메모리 보호 메커니즘. 플래그 형식이므로 비트 연산으로 복수 속성으로 지정 가능하다.

 + PROT_EXEC; 해당 페이지 실행 가능.

 + PROT_READ; 해당 페이지 읽기 가능.

 + PROT_WRITE; 해당 페이지 쓰기 가능.

 + PROT_NONE; 해당 페이지 접근 불가.

 => 매핑할 파일 디스크립터와 속성이 같아야한다.

- int flags

 + MAP_SHARED; 공유 메모리 맵 방식.

 + MAP_PRIVATE; 복사 메모리 맵 방식.

 + MAP_FIXED ; 메모리 시작 번지 지정시 사용.

 =>MAP_SHARED/MAP_PRIVATE 둘 중에 한개만 지정해야된다.

- int fd

 ; 메모리 맵 방식을 사용할 파일 디스크립터.(파일 혹은 디바이스)

- ott_t offset

 ; 해당 파일 디스크립터에서 메모리 맵을 시작할 오프셋 값.

; 메모리 맵핑이 이루어진 가상 메모리 주소. 실패시 MAP_FAILED가 발생하고 errno에 해당 상황에 대한 값이 설정된다.

* 메모리 맵 해제 - munmap()

; 메모리 맵을 사용하고 자원을 해제 할 때 사용한다.

int munmap(void *start, size_t length);

- void *start

; 메모리 맵핑이 시작된 주소. mmap()의 반환 값을 넣으면된다.

- size_t length

; 메모리 맵을 한 길이. mmap() 사용시 size_t length 인자와 크기를 주면된다.

+ return value

;성공 0, 실패 -1

* 메모리 맵과 파일의 동기화 - fsync()

; 메모리 맵에 데이터를 갱신해도 바로 파일과 동기화가 이루어지는 것은 아니다. 커널이 여유 있을 때 동기화를 수행한다. 그러므로 개발자가 직접 동기화를 보장하고 싶을 때 사용한다. 그리고 munmap()을 하여 메모리 맵을 해제 할때에도 동기화를 해주면 데이터가 보장된다.

int msync(void *start, size_t length, int flags);

- void *start

; mmap()를 통해 리턴 받은 메모리 맵의 시작 주소.

-  size_t length

; 동기화를 할 길이. 시작 주소로 부터 길이를 지정하면 된다.

- int flags

 + MS_ASYNC

 ; 비동기 방식. 동기화(Memory->File)하라는 명령만 내리고 결과에 관계 없이 바로 리턴.

   그렇기 때문에 동기화가 된 건지 알수 없다.

 + MS_SYNC

 ; 동기 방식. 동기화(Memory->File)가 될때까지 블럭 상태로 대기한다.

 + MS_INVALIDATE

 ; 현재 메모리 맵을 무효화하고 파일의 데이터로 갱신. 즉 File->Memory

===================================================================================

       ...

#define MMAP_FULENAME "test_mmap"

#define MMAP_SIZE 64

       ...

int main()

{

     int fd;

     char *p_mmap;      //메모리 맵으로 사용할 데이터 타입

       ...

     fd = open(MMAP_FILENAME, O_RDWR|O_CREAT, 0664);

       ...

     p_mmap = (char*)mmap((void*)0, MMAP_SIZE, PROT_READ|PROT_WRITE,

                                                                     MAP_SHARED, fd, 0);

     //공유 메모리 방식을 사용한다. 읽기/쓰기 가능

       ...

     //memcpy(); 등으로 메모리 맵 데이터 갱신.

       ...

     msync(p_mmap, MAP_SIZE, MS_SYNC);

       ...

     munmap(p_mmap);

     return 0;

}

=> 메모리 맵 할 파일 이름만 같으면 IPC도 된다.

------------------------------------------------------------

출처 : http://hsnote.tistory.com/141

윈도우의 경우는 아래의 자료를 참고.

[메모리 매핑파일]

HANDLE CreateFileMapping(HANDLE hFile,    // (1)
   LPSECURITY_ATTRIBUTES lpAttributes, //(2)
   DWORD flProtect,  // (3)
   DWORD dwMaximumSizeHigh,  // (4)
   DWORD dwMaxImumSizeLow,  // (5)
   LPCTSTR lpName   //(6)
   );

위의 함수가 매모리매핑 파일을 만드는 함수이다..

위의 함수 사용시 매모리맵파일이 생성은 되지만 실제로 매모리에 연결되어 있진않다. 

연결을 하려면 MapViewOfFile 이라는 함수를 써야지 그 때부터 메모리에 연결이 된다.

일단위 함수의 설명을 들어보자

목적 및 하는 일 : MMF라는 커널 객체를 만들고 그 핸들을 리턴한다.
                         메모리매핑파일을 만들수있는 기본정보들을 갖고 있는 커널객체를 만들고 그 핸들을 리턴한다.

인자설명 : 
 (1) hFile  : CreateFile 함수로 해당파일을 열고 리턴받은 값.. (CreaqteFile 의 리턴값  파일핸들) 파일핸들을 인자로 넘겨준다.. , (어떤파일을 파일매핑할건지 정하는거다.)
 
 (2) lpAttributes : 솔직히 잘 모르겠는데 .. 보통 이값은 NULL로 줬다. (아시는 분은 좀 알려주세여^^)

 (3) flProtect : 읽기 전용으로 할건지 읽기 쓰기를 할건지 설정하는 옵션이다. ex) PAGE_READONLY, PAGE_READWRITE 등등

 (3) dwMaximumSizeHigh : 매핑할 범위를 지정하는 상위 4바이트 (용량이 작은 범위라면 이곳에 0을 주고 그 다음 인자에 파일크기 및 원하는 범위를 지정한다.)
 
 (4) dwMaximumSizeLow : 매핑할 범위 지정하는 하위 4바이트

 (5) lpName : 파일매핑 객체이기 때문에 객체에 이름을 부여할때 쓴다. 보통   NULL을 주고 이름을 붙이도 다른곳에서 참조할때는 이름을 문자열로 이름을 지정한다.

사용예제 ) CreateFileMapping(hSource, NULL, PAGE_READONLY, 0, dwFileSize, NULL);
 
 CreateFileMapping(hTarget, NULL, PAGE_READWRITE, 0, dwFileSize, NULL);

------------------------------------------------------------------------------------------------------------------------------

LPVOID MapViewOfFile(HANDLE hFileMappingObject, // (1)
   DWORD dwDesiredAccess,  // (2)
   DWORD dwFileOffsetHigh,  //(3)
   DWORD dwFileOffsetLow,   // (4)
   SIZE_T dwNumberOfBytesToMap   // (5)
  );

목적 및 하는 일 : CreateFileMapping 함수로 만든 MMF 객체를 대상으로 실제 메모리번지에 연결을 하여 메모리 매핑파일을 만든다.
  메모리 매핑파일 만들고 그 메모리의 시작번지를 리턴한다.

인자설명 :
 (1) hFileMappingObject : CreateFileMapping 함수로 리턴받은 핸들값을 인자로 준다.

 (2) dwDesireAccess : 접근권한을 설정하는 것으로 FILE_MAP_READ, FILE_MAP,WRITE 등으로 옵션을 준다.

 (3) dwFileOffsetHigh :  메모리 주소가 연결될 크기 상위 4바이트

 (4) dwFileOffsetLow : 메모리 주소가 연결될 크기 하위 4바이트

 (5) dwNumberOfBytesToMap : 오프셋으로 부터 원하는 크기를 정한다.

사용예제 ) MapViewOfFile(hMapSource, FILE_MAP_READ, 0, dwAs, dwLen);

 MapViewOfFile(hMapTarget, FILE_MAP_WRITE, 0, dwAs, dwLen);

------------------------------------------------------------------------------------------------------------------------------

해당함수들을 사용후에는 해제 해주어야 하는데

CreateFileMapping 함수 같은 경우 파일 핸들을 리턴함으로

CloseHandle(리턴값); 으로 해제하고

MapViewOfFile 함수 같은 경우는 메모리 주소를 리턴함으로

UnmapViewOfFile(리턴값); 으로 해제한다.

------------------------------------------------------------------------------------------------------------------------------ 

===================================================================================================

[gcc 컴파일]

1) gcc 파일명(*.c) : Default로 out 파일이 생성된다. (ex a.out)

2) gcc -c 파일명(*.c) : 오브젝트 파일을 생성한다.

3) gcc -c 오브젝트_파일명(*.o) 파일명(*.c)

   gcc -o 실행파일명(*.out) 오브젝트_파일명(*.o)

4) gcc -o 실행파일 파일명(*.c) : 실행 파일을 만든다. (3번을 한줄로...)

===================================================================================================

[gcc 옵션]

1. -Wall 옵션 : 모든 모호한 코딩에 대해서 경고를 보내는 옵션

2. -W 옵션 : 합법적이지만 모호한 코딩에 대해서 경고를 보내는 옵션

3. -W -Wall 옵션 : 아주 사소한 모호성에 대해서도 경고가 발생

4. O2 옵션 : 최적화 레벨 2로 설정. (대부분의 최적화를 시도)

5. -E 옵션 : 전처리 과정의 결과를 화면에 보이는 옵션 

             (전처리과정 중 발생한 오류를 검증)

    ※ enhanced Tip: --save-temps 옵션 

6. -S 옵션 : cc1으로 전처리된 파일을 어셈블리 파일로 

             컴파일까지만 수행하고 멈춘다. (*.s)

7. -c 옵션 : as에 의한 어셈블까지만 수행하고 링크는 수행하지 않는다.

8. -v 옵션 : gcc가 컴파일을 어떤 식으로 수행하는지를 화면에 출력한다.

9. --save-temps 옵션 : 컴파일 과정에서 생성되는 중간 파일인 

                       전처리 파일(*.i)과 어셈블리 파일(*.s)을 지우지 않고,

                       현재 디렉토리에 저장한다. (오류 분석에 사용)

===================================================================================================

[cpp0 옵션]

: 소스내에서 사용된 헤더 파일과 define 매크로와 관련된 옵션들이다.

  전처리 과정에서 오류가 발생한다면 cpp0 옵션들을 점검해야 한다.

1) -l 옵션 : 전처리 과정에서 헤더 파일을 탐색하는 기본 디렉토리를 추가할 때 사용하는 옵션

2) -include 옵션 : 헤더 파일을 소스내에 추가할 때 사용한다.

3) -D[매크로] 옵션 : 매크로를 외부에서 define 할 때 사용한다.

4) -D[매크로]=[매크로 값] 옵션 : 소스 내에 #define [매크로] [매크로 값] 옵션을 추가한 것과 

                                 동일하다.

5) -U[매크로] 옵션 : -D와 반대로 소스 파일 내에 #undef[매크로] 옵션을 추가한 것과 

                     동일하다.

6) -M / -MM 옵션 : -M 옵션 - make를 위한 소스 파일의 모든 종속 항목을 출력

                   -MM 옵션 - 기본 include 디렉토리에 있는 헤더 파일은 빼고 종속 항목을

                              출력한다.

7) -nostdinc 옵션 : 디폴트 include 디렉토리(usr/include)에서 헤더 파일을 탐색하지 않고,

                    -l 옵션으로 추가한 디렉토리에서만 헤더 파일을 찾는다.

8) -C 옵션 : -E 옵션과 함께 사용하며, 전처리 과정에서 주석을 제거하지 않는다.

9) -Wp,[옵션들] 옵션 : 만약 cpp0와 gcc의 옵션이 같은 것으로 중복되면 gcc 옵션으로 

                       해석되므로... gcc의 해석을 거치지 않고 바로 cpp0 옵션으로 전달하고 

                       싶을 때 사용한다.         

===================================================================================================

[cc1 옵션]

: "C언어 옵션, 경고 옵션, 최적화 옵션, 디버깅 옵션"의 4가지 종류

  "경고 수위 조절 or 최적화 수위 조절"을 하고 싶을 때 사용한다.

1. C언어 옵션 : C언어 종류와 표준에 관련된 옵션

   1) -ansi 옵션 : ANSI C 표준에 부합하는 소스를 작성하고자 할 때 사용하는 옵션

   2) -std=[C 표준들] 옵션 : 기타 다른 표준들을 지정하고자 할 때 사용한다.

   3) -traditional 옵션 : 오래된 Traditional C 문법으로 문법을 검사한다.

   4) -fno -asm 옵션 : gnu89 문법을 바탕으로 asm, inline, typeof 키워드를 사용하지 않기를

                       원할 때 사용한다.

2. 경고 옵션 : cc1의 옵션을 조정하여 경고 수위를 조절할 수 있다.

   1) -W / -Wall 옵션 (gcc 옵션 참고)

   2) -w(소문자) 옵션 : 모든 경고 메시지를 제거한다.

   3) -Werror 옵션 : 모든 경고를 컴파일을 중단하는 오류로 취급한다.

                     (경고가 하나만 나와도 컴파일이 중단된다.)

   4) -pedantic 옵션 : ANSI C89 표준에서 요구하는 모든 경고 메시지를 표시한다.

   5) -pedantic-errors 옵션 : ANSI C89 표준에서 요구하는 모든 오류 메시지를 표시한다.

   6) -Wtraditional 옵션 : 소스가 ANSI C와 K&R C 간에 서로 다른 결과를 가져올 수 있는

                           부분이 있다면 경고한다.

3. 최적화 옵션 : ⓐ 실행 파일의 크기를 줄여 메모리와 하드디스크의 사이즈를 절약 (큰 의미 X)

                 ⓑ 실행 파일의 크기를 줄여 실행 속도를 향상시키는 것.

   1) -O0 옵션 : 최적화를 수행하지 않는다.

   2) -O1 옵션 : -O0보다는 조금 낫다. 

   3) -O2 옵션 : 가장 많이 사용하는 옵션. 일반 응용 프로그램이나 커널을 컴파일 할 때 사용

                 (거의 대부분의 최적화를 수행한다.)

   4) -O3 옵션 : 가장 높은 레벨의 최적화. 모든 함수를 인라인 함수와 같이 취급한다.               

                 (Call 인스트럭션은 사용 X. but, 되도록이면 사용하지 않는 것이 좋다. 

                   → 너무나 많은 소스의 변경이 가해지기 때문에 왜곡이 발생할 위험이 있다.)

   5) -O5 옵션 : 사이즈 최적화를 실행한다. (공간이 협소한 곳에서 사용 - 임베디드 시스템)

4. 디버깅 옵션

   1) -g 옵션 : gdb에게 제공하는 정보를 바이너리에 삽입한다.

                (-g 옵션을 사용하지 않고 gdb로 디버깅하면, 역어셈 → 어셈블리 코드로만 디버깅 가능)

   2) -pg 옵션 : 프로파일을 위한 코드를 삽입한다. 

                 (-pg 옵션으로 컴파일 → gmon.out(프로파일 정보) → gprof로 gmon.out 파일 분석)

===================================================================================================

[as의 옵션]

: gcc는 as의 옵션에 대해서는 알지 못한다. -Wa,[as 옵션들] 형식으로 gcc를 거치지 않고 

  바로 전달해야 한다. -Wa, -al, -as와 같은 형식으로 사용하면 as에게 -al -as 옵션이 같이 전해진다.

-Wa,[as 옵션들]

1) -al 옵션 : 어셈블된 인스트럭션을 보인다.

2) -as 옵션 : 정의된 심볼을 보인다.

3) -l[패스] 옵션 : include 디렉토리를 지정한다. 어셈블리 소스 내에서 사용된 include 지정자가 

                   지정하는 헤더파일을 찾고자 할 때 사용한다.

4) -W / --no-warn : 경고 메시지를 출력하지 않는다.

5) -march=[아키텍처 문자열] : 해당 어셈블리

===================================================================================================

[collect2 / ld 옵션]

: 링크 옵션

1) -L[라이브러리 디렉토리] 옵션 : 라이브러리를 찾을 디렉토리를 지정한다.

2) -l 옵션 : 같이 링크할 라이브러리를 지정한다.

3) -shared 옵션 : 공유 라이브러리와 정적 라이브러리가 같이 있을 경우, 공유 라이브러리를 우선하여

                  링크한다. (아무 옵션을 주지 않아도 공유 라이브러리를 우선으로 링크한다.)

4) -static 옵션 : 정적 라이브러리와 공유 라이브러리가 같이 있다면, 정적 라이브러리를 우선하여

                  링크한다. (속도는 빠르지만 파일 사이즈가 커진다는 점 고려할 것!)

5) -nostdlib 옵션 : 링크시에 표준 C 라이브러리를 사용하지 않는다. 

                    (OS, 부트로더와 같은 프로그램을 컴파일 할 때 사용)

6) -nostartfiles 옵션 : crt1.o 등과 같은 start up 파일을 링크하지 않는다.

                    (OS, 부트로더와 같은 프로그램을 컴파일 할 때 사용)

7) -Wl,[링크 옵션들] 옵션 : gcc를 거치지 않고 바로 링크에게 옵션을 정해주고자 할 때 사용한다.

                            (사용법은 -Wa와 동일한다.)

   < 유용한 링크 옵션들 >

   ① -s 옵션 : 실행 파일에서 심볼 테이블을 제거

   ② -x 옵션 : 출력 파일에서 로컬 심볼 제거

   ③ -n 옵션 : 텍스트 영역을 읽기 전용으로 만듬

   ④ -r 옵션 : 추후 링크가 가능하게 오브젝트를 만듬

   ⑤ -e [name] 옵션 :  시작 심볼을 name 심볼로 사용 (default 시작심볼 : _start 심볼)

   ⑥ -M 옵션 : 심볼들의 정보를 자세하게 출력

   ⑦ oformat [format] 옵션 : 주어진 형식의 오브젝트 파일을 생성

===================================================================================================

출처 : http://lvzuufx.blogspot.kr/2014/09/gnu-make-gcc-auto-dependency-makefile.html

Autotools, CMake, qmake 같은 빌드 도구나 Open Watcom 의 wmake 같은 경우에는 자체적으로 auto-dependency 를 지원하거나 이를 위한 지시자를 제공한다. 하지만 GNU Make 의 경우에는 이러한 기능을 자체적으로 지원하지도 않고, 이를 위한 지시자를 제공하지도 않는다.

하지만, 다행히도 gcc 를 이용해서 이 기능을 구현할 수 있다. 우선 이에 필요한 gcc 의 기능부터 살펴보자. 

-M 옵션 : 해당 소스 파일의 의존성을 GNU Make 의존성 규칙에 맞추어 출력한다. 시스템 헤더 파일들도 포함된다.

예를 들어, 다음과 같은 hello.c 를 생각해보자.

• gcc -M hello.c

이를 실행한 결과는 이렇다.

• hello.o: hello.c f:/lang/gcc/usr/include/stdio.h \
•   f:/lang/gcc/usr/include/sys/cdefs.h \
•   f:/lang/gcc/usr/include/sys/gnu/cdefs.h \
•   f:/lang/gcc/usr/include/features.h f:/lang/gcc/usr/include/sys/_types.h \
•   f:/lang/gcc/usr/include/machine/_types.h \
•   f:/lang/gcc/usr/include/386/_types.h

-MM 옵션 : -M 옵션과 비슷한데, 시스템 헤더 파일은 제외한다.

• gcc -MM hello.c 

다음은 실행 결과이다.

•  hello.o: hello.c

 -MP 옵션 : -M 또는 -MM 옵션과 함께 쓰일 때, 헤더 파일들에 대한 phony 타겟을 만든다. 이는 헤더 파일이 지워졌을 때, 오류가 발생하는 것을 방지한다.

•  gcc -M -MP hello.c

다음은 실행 결과이다.

•  hello.o: hello.c f:/lang/gcc/usr/include/stdio.h \
•   f:/lang/gcc/usr/include/sys/cdefs.h \
•   f:/lang/gcc/usr/include/sys/gnu/cdefs.h \
•   f:/lang/gcc/usr/include/features.h f:/lang/gcc/usr/include/sys/_types.h \
•   f:/lang/gcc/usr/include/machine/_types.h \
•   f:/lang/gcc/usr/include/386/_types.h
• f:/lang/gcc/usr/include/stdio.h:
• f:/lang/gcc/usr/include/sys/cdefs.h:
• f:/lang/gcc/usr/include/sys/gnu/cdefs.h:
• f:/lang/gcc/usr/include/features.h:
• f:/lang/gcc/usr/include/sys/_types.h:
• f:/lang/gcc/usr/include/machine/_types.h:
• f:/lang/gcc/usr/include/386/_types.h: 

-MT 옵션 : -M 또는 -MM 옵션과 함께 쓰일 때, 타겟의 이름을 바꾼다.

• gcc -M -MT hello_MT.o hello.c

다음은 실행 결과이다.

• hello_MT.o: hello.c f:/lang/gcc/usr/include/stdio.h \
•   f:/lang/gcc/usr/include/sys/cdefs.h \
•   f:/lang/gcc/usr/include/sys/gnu/cdefs.h \
•   f:/lang/gcc/usr/include/features.h f:/lang/gcc/usr/include/sys/_types.h \
•   f:/lang/gcc/usr/include/machine/_types.h \
•   f:/lang/gcc/usr/include/386/_types.h

-MF 옵션 : -M 또는 -MM 옵션과 함께 쓰일 때, 출력 결과를 해당 장치 또는 파일로 보낸다.

• gcc -M -MF hello.d hello.c

이 때 실행 결과는 표준 출력 장치에 나타나는 것이 아니라 hello.d 라는 파일에 저장된다.

바로 이 옵션들을 통해서 auto-dependecy Makefile 파일을 만들 수 있다. 문제는 이 내용을 Makefile 파일에서 어떻게 활용할 것인가이다.

의존성 파일부터 만들어 보자. 의존성 파일을 만들기 위한 기본적인 형태는 다음과 같다.

• hello.d : hello.c
•     gcc -M -MP -MF $@ $<

이제는 이렇게 만들어진 의존성 파일을 포함시켜야 한다. GNU Make는 이를 위해 include 지시자를 지원한다.

• include hello.d

이때 hello.d 가 없다면 주어진 생성 규칙을 통해서 새로이 만들거나 갱신한다. 그럼에도 불구하고 hello.d 를 만들 수 없다면, GNU Make 는 오류를 보고하고, 중지한다.

마지막으로 실행 파일의 의존성 규칙을 추가해주면 된다.

•  hello.exe : hello.o

물론 다음과 같은 기본적인 내용이 Makefile 앞 부분에 더 추가되어야 한다.

• .SUFFIXES : .c .o .exe
•  
• .PHONY : all
•  
• all : hello.exe

완성된 Makefile 의 모습은 이렇다.

이제 make 를 실행하면, hello.c 자체가 수정되거나 hello.c 가 포함하는 헤더 파일이 수정되면 새롭게 빌드된다.

그런데 문제는 hello.d 파일 자체는 한 번 만들어지면 hello.c 가 수정되지 않는 이상, 다시 갱신되지 않는다. 왜냐하면 hello.d 파일에 대한 의존성은 hello.c 밖에 없기 때문이다. 이 문제는 hello.d 의 의존성을 hello.o 의 의존성과 동일하게 만들어주면 된다. 위 8번째 줄을 아래와 같이 바꾸자.

• gcc -M -MP -MT "$(@:.d=.o) $@" -MF $@ $<

GNU Make 의 다중 대상 기능을 이용한 것으로. 타겟이 "hello.o" 에서 "hello.o hello.d" 로 된다.

GNU Make 를 실행하다보면 hello.d 가 지워진 경우에,  다음과 같은 오류 메세지가 출력된다.

• Makefile:10: hello.d: No such file or directory

이 오류 메세지가 나오더라도 중단되지는 않지만, 뭔가 꺼림칙하다. 어떻게 없앨 수 없을까 ? 바로 -include 를 쓰면 된다.

이 예제의 경우에는 소스 파일이 하나에 불과해서 이 정도이지만, 소스 파일이 여러 개일 경우에는 해당 소스 파일마다 일일이 추가해줘야 한다. 그리고 다른 프로젝트에 쓰기에도 수정해야 할 것이 많다. 이 얼마나 불편한가 ? 이를 개선해 보자.

우리가 고려할 것은 실행 파일과, 소스 파일이다. 다른 모든 것들은 이들로부터 변형될 수 있다. 이들을 위한 변수를 도입하자. PROGNAME 과 SRCS 에 실행파일과 소스 파일을 담자.

• PROGNAME := hello.exe
• SRCS := hello.c

이제 의존성 파일 변수와 실행 파일을 만들기 위한 목적 파일 변수를 도입하자.

• PROGNAME_DEPS := $(SRCS:.c=.o)
• DEPS := $(SRCS:.c=.d)

이 내용들을 반영하면 위 Makefile 은 다음과 같이 쓰여질 수 있다.

위 내용을 보면 특정 이름 대신에 변수를 사용한 것 외에도 몇 가지 달라진 점이 있는데, 하나는 16번째 줄에 있는 암묵적 규칙이고, 14번째 줄에 있는 $^ 이다. 암묵적 규칙은 여러개의 파일에 대해 동일한 규칙을  적용하기 위한 것이고, $^ 은 모든 의존 파일들을 뜻한다. 반면에 $< 은 첫번째 의존 파일을 뜻한다.
이렇게 해 두면, 다른 프로젝트에 적용을 한다든지 또는 소스가 변경되었다든지 할 때, PROGRAM 과 SRCS 만 바꾸어주면 된다. 소스 파일을 더 추가하고 싶다면 빈 칸을 사이에 두고 파일 이름을 적어주면 된다. 예를 들어 hello.c 외에 world.c 가 추가되었다면 2번째 줄을 이렇게 바꾸면 된다.

• SRCS := hello.c world.c

이외에도 여러가지 컴파일 플래그나 링커 플래그, 컴파일러나 링커를 위한 여러 변수들을 도입하면 훨씬 더 유연한 Makefile 이 될 것이다.

그리고 기회가 된다면 추후에 여러 개의 실행 파일과 DLL 등을 한꺼번에 빌드할 수 있는 Makefile 에 대해서도 글을 쓰도록 하겠다. 

출처 : http://ospace.tistory.com/189

소켓 관련 자세한 내용 joinc를 참고!!

: http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Network_Programing/AdvancedComm/SocketOption

들어가기

int connect(int, const struct sockaddr*, socklen_t); // for linux

int connect(SOCKET, const struct sockaddr*, int); // for windows

int getsockopt(int, int, int, void*, socklen_t*); // for linux
int getsockopt(SOCKET, int, int char*, int*);   // for windows

int error = 0;
socklen_t len = sizeof( error );
if( getsockopt(fd, SOL_SOCKET, SO_ERROR, &error, &len) < 0 ) {
    // 값을 가져오는데 에러 발생
    // errno을 가지고 에러 값을 출력
    // 연결 오류로 처리
}

int fd = socket(AF_INET, SOCK_STREAM, 0); // tcp socket
if( fcntl( fd, F_SETFL, O_NONBLOCK) == -1 ) {
    return -1; // error
}
// Windows인 경우
// unsigned long nonblock = 1; 
// nonblock 설정
// ioctlsocket(fd, FIONBIO, &nonblock);
// struct sockaddr_in 형의 peer를 초기화함
int result = connect (fd, (struct sockaddr*)&peer, sizeof(peer));
if( 0 == result ) {
    // 연결 성공
} else if ( EINPROGRESS == errno ) {
    // 비동기 연결 이벤트로 등록
} else {
    // 연결 실패
}

// 연결 이벤트 헨들러
int error = 0;
socklen_t err_len = sizeof(error);
if( getsockopt(fd, SOL_SOCKET, SO_ERROR, (void*) &error, &len) < 0 ) {
    // 결과값 갖고 오는데 에러 발생
    // 연결중 에러 발생으로 errno 값으로 결과 확인
    // 에러 리턴
}
if( 0 != error ) {
    if( ECONNREFUSED == error ) {
        // 연결 거부로 연결 실패
        // 에러 처리
    } else if( ETIMEOUT == error ) {
        // 연결 대기 시간 초과로 연결 실패
        // 에러 처리
    }
    // 원인 모를 에러?
    // 알아서 처리 ㅡ.ㅡ;
}
// error가 0이기 때문에 연결 성공 ^^

UNIX에서는 Winsock과 다르다고 하네요
UNIX에서는 연결이 성공했는지의 여부를 알리기 위해서
읽기와 쓰기가 모두 가능하게 만듭니다.
커널 구현이 그런걸 ... 왜 그렇냐고 따지기 보다 ㅎㅎ 그냥 쓰셔야 겠죠

일단 select() 리턴후

readable도 아니고 writable도 아니라면
소켓은 연결이 되어 있는 상태로 판단가능하구요

그다음엔
getpeername()을 호출해서 정상리턴이면 연결된 상태입니다.

만약 getpeername()이 ENOTCONN을 리턴하면 연결안된상태이구요.
getsockopt() 호출해줘서 아직 가지고 오지 않은 에러코드를 가지고 오신후에 error코드를 살펴보시면 됩니다.
만약 getsockopt() 자체가 실패하면
errno가 getsockopt()호출에 대한 실패를 저장하겠죠?(맞나 ㅡ.ㅡ, 불확실..)

제가 말씀 드린 부분을 isconnected() 함수로 만들어서

사용하시면 될것 같네요

--------------------------------------------------------------------------------------------------------

일단 저의 상황에 대해 말씀드리자면

우선 가장 정답에 대해서 말하자면 포인터를 선언할때는 

1. 변수 선언시 NULL로 초기화 해줘야 한다.

2. new 로 생성한 객체를 delete 한 뒤에는 NULL로 다시 초기화 해준다.

위와 같은 사실 이전에 한가지 의문이 있는데

delete는 NULL pointer에 대해 safe 한가?

MEC++ (More Effective C++)에는 C++ 에서는 safe to null pointer 라고 명시되어 있다.

즉 NULL 포인터를 delete를 해도 null pointer exception error가 발생하지 않는다는 것.

즉 이러한 코드는 필요가 없는 것이다.

if(var) delete var;

일단 테스트 해본 결과 메모리 릭이 발생하는 것은 아니지만 일반적으로 매크로를 사용해서 NULL로 다시 초기화 해준다. 

(디버깅이 문제가 될 수 있어 template나 공용함수를 사용해도 무방)

#define SAFE_DELETE(var)    { delete var; var = NULL; }

_open

_O_APPEND

모든 쓰기 작업 전에 파일 포인터를 파일 끝으로 이동한다.

_O_BINARY

모드로 파일을 연다. (fopen 참고)

_O_CREAT

쓰기위해 생성하고 새로 만든 파일을 연다. 만약 이미 존재한 파일이면 아무런 효과가 없다. _O_CREAT가 쓰일 때 pmode 인자를 필요로 한다.

_O_CREAT | _O_SHORT_LIVED

만약 디스크에서 flush가 가능 하지 않을때 임시로서 파일을 생성한다. _O_CREAT가 쓰일 때 pmode 인자를 필요로 한다.

_O_CREAT | _O_TEMPORARY

임시로 파일을 생성한다.; 마지막 파일 descriptor가 닫혀질때 파일은 삭제된다. O_CREAT가 쓰일 때 pmode 인자를 필요로 한다.

_O_CREAT | _O_EXCL

파일이 이미 존재한다면 에러를 리턴한다. 오직 _O_CREAT일때만 적.

_O_RANDOM

Specifies that caching is optimized for, but not restricted to, random access from disk.

_O_RDONLY

오직 읽기위해 연다.; O_RDWR or _O_WRONLY와 함께 쓰여질 수 없다.

_O_RDWR

읽고 쓰기위해 연다.; _O_RDONLY or _O_WRONLY와 함께 쓰여질 수 없다.

_O_SEQUENTIAL

Specifies that caching is optimized for, but not restricted to, sequential access from disk.

_O_TEXT

text모드로 변환되어 연다. (더 많은 정보는 Text and Binary Mode File I/O 과 fopen 참고.)

_O_TRUNC

Opens file and truncates it to zero length; file must have write permission. You cannot specify this flag with _O_RDONLY. _O_TRUNC used with _O_CREAT opens an existing file or creates a new file.

Note The _O_TRUNC flag destroys the contents of the specified file.

_O_WRONLY

오직 쓰기위해 연다.; _O_RDONLY 또는 _O_RDWR와 함께 쓰여질 수 없다.

밑에 있는 플래그는 SYS\STAT.H 에 정의 되어있다.

_S_IREAD

오직 읽기만 허락됨.

_S_IWRITE

쓰기가 허락됨(실제로 쓰기, 읽기가 허락됨).

_S_IREAD | _S_IWRITE

쓰기, 읽기가 허락됨.

_close

_read

_write

_lseek - FP를 특정한 위치로 이동한다.

출처 : http://blog.naver.com/dalmagru?Redirect=Log&logNo=70068719762

wait(), waitpid() : 부모 프로세스가 자식 프로세스가 종료했음을 확인하는 함수.

waitpid() : 인자로 프로세스ID를 받음으로써 특정 자식 프로세스의 종료를 기다릴수 있다.

함수원형

※ 자식 프로세스의 상태를 확인하는 매크로들

※ waitpid()에서 사용하는 pid인자값의 의미

※ waitpid()에서 사용하는 option인자

※ 좀비 프로세스 (zombie process) : 자식 프로세스가 종료되었지만, 부모 프로세스가 아직 그 종료를 확인하지 않는 프로세스

※ 고아 프로세스 : 자식보다 먼저 부모프로세스가 죽었을 경우의 자식 프로세스.