Co robi NSRunLoop?

Question

Przeczytałem wiele wpisów na temat NSRunLoop, takich jak this, this, this. Ale nie może dowiedzieć się, co faktycznie robi NSRunLoop

Co ja zwykle zobaczyć to wątek pracownik

wthread = [[NSThread alloc] initWithTarget:self selector:@selector(threadProc) object:nil]; 
[wthread start]; 

z NSRunLoop środku

- (void)threadProc 
{ 
    NSAutoreleasePool* pool1 = [[NSAutoreleasePool alloc] init]; 
    BOOL isStopped = NO; 
    NSRunLoop *runloop = [NSRunLoop currentRunLoop]; 
    [runloop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode]; 

    while (!isStopped) 
    { 
     { 
      NSAutoreleasePool* pool2 = [[NSAutoreleasePool alloc] init]; 
      [runloop runMode:NSDefaultRunLoopMode 
             beforeDate:[NSDate distantFuture]]; 

      [pool2 release]; 
     } 
    } 

    [pool1 release]; 
} 

A głównym wątku przechodzi jakąś pracę do tego wthread

[self performSelector:@selector(someWork:) onThread:wthread withObject:nil waitUntilDone:NO]; 

Pod względem przekazywania pracy z głównego wątku do wor Wątek, widzę, że wielu ludzi to robi. Dlaczego potrzebujesz NSRunLoop tutaj? Co to robi ?

Przeczytałem, że NSRunLoop służy do zarządzania zdarzeniami, dlaczego nie ma nic oprócz wywoływania runMode wewnątrz threadProc?

Answer 1

Przykład, który pokazałeś, to idiom kakao do tworzenia wątku, który będzie kontynuowany po wyjściu z metody -threadProc. Czemu?

Ponieważ:

• utworzeniu instancji NSRunLoop ma co najmniej jedno źródło sygnału wejściowego ([NSMachPort port])
• już wyraźnie zaczął pętlę biegu z runMode:beforeDate

Bez dodawania źródło wejściowe i jawnie uruchamiające pętlę uruchamiania, wątek zakończyłby się.

Nawiasem mówiąc, mimo że pętle uruchomieniowe są nadal niezbędne do zarządzania zdarzeniami i pewnymi zadaniami asynchronicznymi, nie będę postrzegał NSThread jako domyślnego sposobu projektowania najbardziej asynchronicznych prac w aplikacji Cocoa w dzisiejszych czasach. GCD jest znacznie czystszym sposobem zamykania pracy w tle.

EDIT:

Składanie prac do kolejki szeregowego w GCD:

@interface Foo : NSObject 
@end 

@implementation Foo { 
    dispatch_queue_t _someWorkerQueue; 
} 

- (id)init { 
    self = [super init]; 
    if(!self) return nil; 

    _someWorkerQueue = dispatch_queue_create("com.company.MyWorkerQueue", 0); 
    return self; 
} 

- (void)performJob { 
    dispatch_async(_someWorkerQueue, ^{ 
     //do some work asynchronously here 
    }); 

    dispatch_async(_someWorkerQueue, ^{ 
     //more asynchronous work here 
    }); 
} 
@end 

Answer 2

Wiele dzieje się za sceną. Powodem tego jest to, że wątek przestaje być wykonywany, gdy nie ma żadnych elementów pracy. Jeśli kiedykolwiek korzystałeś z systemu operacyjnego w czasie rzeczywistym, zadania wymagają miejsca, aby zrezygnować z procesora, aby inni mogli działać.

To, co nie jest dobrze udokumentowane, polega na tym, że podczas wysyłania performSelector: onThread: ..., jest to pętla uruchamiająca, która umieszcza wiadomość w kolejce i budzi się, aby wątek mógł ją przetworzyć. Jeśli dodasz komunikaty do pętli while, możesz to zobaczyć.

Dla naprawdę ciekawych jest przykładowy kod na githubie, na którym możesz grać z pętlami startowymi - dodaj komentarz, a ja wymienię kilka.