그랜드 센트럴 디스패치 I/O 채널의 올바른 처분

Question

Grand Central Dispatch I/O 채널을 올바르게 처리하는 방법에 대해 혼란스러워합니다. ,

- (void)beginReading { 
    dispatch_io_t channel; 
    channel = dispatch_io_create_with_path(DISPATCH_IO_RANDOM, 
              "/Path/To/Some/File", 
              O_RDONLY, 
              0 /*mode*/, 
              someQueue, 
              ^(int errorCode) { 
               // Cleanup handler; executed once channel is closed. 
               // (Or fails to open.) 
              }); 
    // Schedule the read operation 
    dispatch_io_read(channel, 0, SIZE_MAX, someQueue, ^(bool done, dispatch_data_t data, int errorCode) { 
     NSError *error = (errorCode!=0) ? [NSError errorWithDomain:NSPOSIXErrorDomain code:errorCode userInfo:nil] : nil; 
     [self didReadChunk:data isEOF:done error:error]; 
    }); 

    // No more read operations to come, so we can safely close the channel. 
    // (Or can we?) 
    dispatch_io_close(channel, 0); 

    // We don't need a reference to the channel anymore 
    dispatch_release(channel); 
} 

내가 dispatch_io_close() 일정 일부 비동기 작업이 채널을 닫습니다 같은데요,이 작업은 실행이 완료 될 때까지 : BUG IN CLIENT OF LIBDISPATCH: Over-resume of an object 다음 (간체) 예는 메시지와 함께 일부 민간 파견 큐에 충돌이 발생 채널에 dispatch_release()으로 전화하지 마십시오. 그렇지 않으면 나쁜 일이 일어납니다. 그러나 이것은 매우 놀랍습니다. dispatch_async()과 같은 다른 GCD 비동기 함수에는이 제한이 없습니다. 또한 dispatch_io_close() 호출은 채널에서 마지막 호출 인 dispatch_release()을 사용하여 파일을 닫는 것처럼 보이므로 엄격하게 필요하지는 않습니다.

dispatch_io_close으로 전화를 걸면 정리 처리기가 실행될 때까지 채널을 해제하지 않도록주의해야합니다. 이것은 너무 짜증나서 그것이 버그인지 궁금합니다. 아니면 뭔가를 놓친거야?

Answer 1

버그 (레이더 # 10246694)가 있습니다. 추가 실험은 경로 기반 디스패치 채널, 즉 dispatch_io_create()과 대조적으로 dispatch_io_create_with_path()으로 생성 된 경로에만 영향을 미친다는 것을 나타내는 것으로 보입니다.