NSThread

Amin Negm-Awad · 10. Mai 2012, 16:03

OS X NoobCoder schrieb:

Das ist ja die ganze Zeit meine Frage wie ich es schaffe einen eigenen Thread zu starten der weder den mainthread blockiert und zudem warten soll bis der Thread fertig ist.

Ich hab schon soviel gelesen komm aber leider nicht auf nen grünen zweig....

Wenn der Mainthread blockiert sein soll, wieso startest du einen weiteren Thread? Was hindert dich daran, $whatever gleich im Mainthread zu machen? Dann ist der nämlich garantiert blockiert.

OS X NoobCoder · 10. Mai 2012, 16:06

Da hast du mich falsch verstanden

der Mainthread soll nicht blockiert werden, damit der Benutzer trotzdem währen dessen die Möglichkeit hat etwas zu machen.

Amin Negm-Awad · 10. Mai 2012, 16:10

"Kann man da jetzt auch noch so etwas wie waitUntilDone setzten?"

Was soll der Benutzer denn machen können? Alles?

Lösungsmöglichkeiten:

1. Modal-Session (aka keine Threads).
2. Nachricht aus dem Thread an den Mainthread, dass er fertig ist.

robin_ · 10. Mai 2012, 16:14

Du könntest das mit NSNotificaionts lösen, falls diese unter Mac OS X vertreten sind.. ich denke schon

OS X NoobCoder · 10. Mai 2012, 16:15

Ja der Benutzer soll alles machen können. Eigentlich fast das selbe wie performonBackground nur dass man da leider auch kein Waituntildone setzten kann
-.-
ICh denke du kennst dich da um einiges besser aus als ich :whistling:

.
Was wäre da jetzt die besser Lösung und von der performance her am schnellsten?

robin_ · 10. Mai 2012, 16:19

Wegen Performance macht man sich erst sorgen, wenns man sie bemerkt... Das ist so ne Faustregel.
Hinzukommt: gibt es performSelectorInBackground unter Mac OS X Lion? Weil dann kannst du ja peformSelectorInBackground machen, dort was machen, das mit einer Notifikation in den MainThread schicken...

OS X NoobCoder · 10. Mai 2012, 16:21

Doch in dem Fall schon, denn man merkt es, da er ca 500 GeocodeAnfragen durchführt. Wenn das alles auf dem Mainthread läuft kann es schonmal bissl dauern bis der Benutzer wieder was machen kann...

robin_ · 10. Mai 2012, 16:24

Wie gesagt, die Methode die das macht in den BG schicken und dann eine NSNotification posten.

- (void) postNotificationInTheMainthreadWithObject:(id) myObject {
//Posten von Notification

}

die Methode rufst du mit self performSelectorOnMainThread auf und gut ist

Michael · 10. Mai 2012, 16:31

OS X NoobCoder schrieb:

Was wäre da jetzt die besser Lösung und von der performance her am schnellsten?

Von der Performance her ist Dein Versuch, noch einen weiteren "Zwischenthread" einzuziehen, die schlechteste Variante. Denn für die Problemlösung hast du dadurch exakt nichts gewonnen. Der "Zwischenthread" muss dann nämlich dem Mainthread (der soll ja nicht blockiert werden) auch irgendwann mitteilen, dass der Arbeitsthread jetzt fertig ist. Das kann der Arbeitsthread dann aber auch direkt selbst machen. Sinnloser kann man Rechenzeit wirklich nicht verbraten.

Michael

OS X NoobCoder · 10. Mai 2012, 16:32

Tut mir echt leid das hab ich jetzt nicht so ganz verstanden. Also ich rufe

Quellcode

[self performSelectorInBackground:@selector(getDataResultOfRequest:) withObject:nsURLRequest];

auf und dann schicke ich in der Methode performSelectorInBackground eine Notification an den Mainthread dass er fertig ist oder wie=

Michael · 10. Mai 2012, 16:35

OS X NoobCoder schrieb:

Tut mir echt leid das hab ich jetzt nicht so ganz verstanden. Also ich rufe

Quellcode

[self performSelectorInBackground:@selector(getDataResultOfRequest:) withObject:nsURLRequest];

auf und dann schicke ich in der Methode performSelectorInBackground eine Notification an den Mainthread dass er fertig ist oder wie=

Nein, in der Methode getDataResultOfRequest: machst Du das.

Michael

OS X NoobCoder · 10. Mai 2012, 16:41

Und so wird PerformSelectorInBackground solange nicht aufgerufen bis ich eine Notification an den Mainthread sende

Michael · 10. Mai 2012, 16:50

Nein, wie kommst du da drauf?

Michael

OS X NoobCoder · 10. Mai 2012, 16:52

ich will ja dass der Thread warten soll bist der vorherige abgeschlossen ist aber das eben nicht auf dem mainthread

Michael · 10. Mai 2012, 17:21

Welcher Thread denn? Du hast den Mainthread, der soll ja nicht warten. Und Du hast den Arbeitsthread, der soll ja wohl den NSURLRequest abarbeiten. So, und welcher von diesen beiden Threads soll jetzt warten? Jeder weitere Thread ist verbrannte Rechenzeit.

Michael

Amin Negm-Awad · 10. Mai 2012, 17:44

OS X NoobCoder schrieb:

Ja der Benutzer soll alles machen können. Eigentlich fast das selbe wie performonBackground nur dass man da leider auch kein Waituntildone setzten kann
-.-
ICh denke du kennst dich da um einiges besser aus als ich .
Was wäre da jetzt die besser Lösung und von der performance her am schnellsten?

Dann Lösung 2

Amin Negm-Awad · 10. Mai 2012, 17:46

OS X NoobCoder schrieb:

ich will ja dass der Thread warten soll bist der vorherige abgeschlossen ist aber das eben nicht auf dem mainthread

Threads = zwei Dinge gleichzeitig.
Warten = zwei Dinge nacheinander.

Threads + Warten = Zwei Dinge gleichzeitig nacheinander?

Wenn du meinst, dass du mehrere Operationen hast, die allesamt in einem Thread erledigt werden sollen, aber jede nach dem Abschluss einer anderen Operation, kannst du das ganz einfach lösen:

1. Alle Operationen in einem Thread
2. NSOperationQueue (Was ohnehin gefühlt 13298721089372198321987 Mal besser ist alsNSThread.)

Amin Negm-Awad · 10. Mai 2012, 17:48

OS X NoobCoder schrieb:

Doch in dem Fall schon, denn man merkt es, da er ca 500 GeocodeAnfragen durchführt. Wenn das alles auf dem Mainthread läuft kann es schonmal bissl dauern bis der Benutzer wieder was machen kann...

Sollen die 500 Abfragen nacheinander (aber gleichzeitig zum Mainthread) bearbeitet werden? Und wieso nacheinander?

Amin Negm-Awad · 10. Mai 2012, 17:50

BTW: Vieles von dem, was ich dazu weiß und was Christian dazu weiß und wie das alles mit Runloops, Threads, Operations, Timern zusammenhängt, haben wir übrigens in Band 2 aufgeschrieben.

Markus Müller · 10. Mai 2012, 17:59

Hier die Lösung