NSThread detachNewThreadSelector는 주 스레드에서 실행

고객의 작은 수는 다음 로그 중지 서명으로 내 OS X 용 응용 프로그램의 중단을 받고 : 로그에서 볼 수 있듯이NSThread detachNewThreadSelector는 주 스레드에서 실행

26 ??? [0x7fff93e87fc9] 
26 ??? [0x7fff93e8372a] 
    26 ??? [0x7fff93e83899] 
    26 __NSThread__main__ + 1318 (Foundation) [0x7fff8be96dfb] 
     26 -[AppController startClean] + 1319 (Housekeeper) [0x100007742] 
     13 -[AppController trashMediaCache:] + 435 (Housekeeper) [0x100010e7a] 
      13 +[MYFileManager trashFilesOfType:inFolder:] + 482 (Housekeeper) [0x100022e2a] 
      13 +[MYFileManager trashFile:] + 22 (Housekeeper) [0x1000227f7] 
       12 +[MYFileManager trashFile:shouldAuth:] + 226 (Housekeeper) [0x1000228de] 
       12 -[NSWorkspace performFileOperation:source:destination:files:tag:] + 319 (AppKit) [0x7fff8aa72bbb] 
        12 -[NSWorkspace _fileOperation:source:destination:files:] + 917 (AppKit) [0x7fff8aa72f7e] 
        12 _FSOperateOnObjectSync + 482 (CarbonCore) [0x7fff87ab309c] 
         12 _NodeOperation + 488 (DesktopServicesPriv) [0x7fff90d6e38a] 
         4 TFSCopyOperation::DoMoveToTrash(TCountedPtr<TCFURLInfo> const&) + 330 (DesktopServicesPriv) [0x7fff90d7e28c] 
          4 TFSInfo::MoveAndRenameTo(TCountedPtr<TFSInfo> const&, TUString*, TCountedPtr<TFSInfo>&) const + 677 (DesktopServicesPriv) [0x7fff90da4ae7] 
          4 TCFURLInfo::RenameWithoutReplacing(char const*, char const*, bool) + 162 (DesktopServicesPriv) [0x7fff90d89620] 
           4 __rename + 10 (libsystem_kernel.dylib) [0x7fff861ba97a] 
           3 <Suppressed> 
         3 TFSCopyOperation::DoMoveToTrash(TCountedPtr<TCFURLInfo> const&) + 1033 (DesktopServicesPriv) [0x7fff90d7e54b] 
          3 THFSPlusPropertyStore::SetProperty(TUString const&, unsigned int, TPropertyReference const&) + 81 (DesktopServicesPriv) [0x7fff90d26bc1] 
          3 TDSMutex::Acquire() + 34 (DesktopServicesPriv) [0x7fff90ce5d00] 
           3 __psynch_mutexwait + 10 (libsystem_kernel.dylib) [0x7fff861ba746] 
           1 <Suppressed> 
         2 TFSCopyOperation::DoMoveToTrash(TCountedPtr<TCFURLInfo> const&) + 995 (DesktopServicesPriv) [0x7fff90d7e525] 
          2 THFSPlusPropertyStore::SetProperty(TUString const&, unsigned int, TPropertyReference const&) + 81 (DesktopServicesPriv) [0x7fff90d26bc1] 
          2 TDSMutex::Acquire() + 34 (DesktopServicesPriv) [0x7fff90ce5d00] 
           2 __psynch_mutexwait + 10 (libsystem_kernel.dylib) [0x7fff861ba746] 
           1 <Suppressed>

이 startClean 메인에서 실행 실. 그러나 혼란스러운 부분은 다음과 같이 startClean에 단 하나의 호출 있다는 것입니다 :

[NSThread detachNewThreadSelector:@selector(startClean) toTarget:self withObject:nil];

그래서 코드는 별도의 스레드에서 실행되어야하고, 참, 그게 내 시스템에서 작동하는 방법이다

하지만,보다 더 한 고객이 OS X 10.9.5에서이 기능을 경험했습니다. startClean 내부의 주 스레드에 대한 호출이 두 개 있지만 UI 업데이트를위한 것입니다. trashMediaCache 호출은 performSelector : withObject :에 의해 실행되지만 performSelectorOnMainThread에는 실행되지 않습니다.

이전에 본 사람이 있습니까? 이것은 OS X 버그입니까, 아니면 시스템이 의도적으로 주 스레드로 호출을 돌리는 상황입니까? 아니면 로그를 잘못 해석 한 것입니까?

P. 나는 디스패치 호출이나 작업 대기열을 사용할 수 있으며 문제를 해결할 수 있지만 여전히 원래 질문에 대한 대답을 알고 싶습니다.

출처

2014-11-13 mwoods

분명히 백그라운드에서 실행되는 startClean 메서드는 주 스레드에서 실행될 일부 코드를 트리거하므로 교착 상태가 발생합니다.
startClean은 코어 데이터을 사용합니다. 이 내용은 here입니다.
또 다른 가능성은 주 스레드에서 실행되는 완료 처리기입니다. 예를 들어 MKLocalSearchCompletionHandler은 문서가 주 스레드에서 항상 실행된다는 것을 명시 적으로 나타냅니다.

출처

2014-11-13 06:45:00

나는 내 자신의 코드를 훑어 보았고 메인 스레드로가는 것은 아무것도 없다는 것이 확실하기 때문에 애플 코드에서 일어날 가능성이 높습니다. 나는 아마 그것의 바닥에 도착하지 않을 것이다. – mwoods

__NSThread__main__은 주 스레드가 아닙니다. NSThread 실행을위한 내부 진입 점입니다.

출처

2014-11-13 07:24:54

아, 그 말이 맞다고 생각합니다. 방금 다른 응용 프로그램에서 응답 보고서를 받았고 호출 스택이'__NSThread__main__' 대신'main'으로 시작되었습니다. – mwoods

NSThread detachNewThreadSelector는 주 스레드에서 실행

답변

관련 문제