methode anhalten

Apfelbeisser · 4. August 2005, 10:16

Quellcode

-(void)sendSqlStats
{
// sql abfragen hier abschicken
[NSThread detachNewThreadSelector:@selector(checkArray:) toTarget:self withObject:nil];
}

Quellcode

-(void)checkArray:(id)arg
{
while(true)
{
// auf ergebnis hier prüfen
// bei erfüllung die Schleife abbrechen und weitere methode ausführen
[NSThread sleepUntilDate:zeitangabe];
...
}
}

Alles anzeigen

ich würd so umsetzen!

Amin Negm-Awad · 4. August 2005, 10:17

Wenn du warten musst, dann musst warten. Was sollen daran Threads ändern?

Es ist übrigens etwas komisch, dass du so genau die Anfrage kennen musst. Was bekommst du denn als Ergebnis-Beschreibung? Reicht dir das nicht? Wenn du das Ergebnis intern übernehmen muss, dann mache das einfach mit den entsprechenden Settern und KVO übernimmt den Rest. Du trittst damit ja eine ganze Maschinerie los.

Amin Negm-Awad · 4. August 2005, 10:19

Ja, das will er aber ja gerade nicht, weil im die while-Schleife anödet, was ich verstehen kann.

Aber wenn er eine Notification bekommt, dann verstehe ich das ganze Problem nicht mehr. Wenn ich ein Ereignis bekomme, muss ich nicht pollen ...

macuser · 4. August 2005, 10:19

Original von Tom9811
Das ist aber kein Problem, welches sich mit Threading oder Semaphoren lösen lässt. Du musst sehen, dass du Anfragen und Antworten matchen kannst.

Was schickt dir denn die Notification an Parametern? Hast du Tags oder Query-IDs?

es ist eine notification von nsfilehandle und die bekommt lediglich ein nsdata geschickt mit dem ergebnis geschickt bekommt. (wir sind hier auf der clientseite nicht auf dem server)

ich kann dir das auch gern am telefon beschreiben, weil es wirklich etwas kompliziert ist.....

Amin Negm-Awad · 4. August 2005, 10:28

es ist eine notification von nsfilehandle und die bekommt lediglich ein nsdata geschickt mit dem ergebnis geschickt bekommt. (wir sind hier auf der clientseite nicht auf dem server)

Ah, verstehe, hattest du auch schon gesagt. Sorry!

Kennst du den File-Handle denn schon beim Absenden der Anfrage? Dann löst sich das Problem recht einfach.

ich kann dir das auch gern am telefon beschreiben, weil es wirklich etwas kompliziert ist.....

Jepp, scheint mir auch so.

0221/8606060 Rechtsanwalt Amin Negm-Awad

macuser · 4. August 2005, 10:30

Original von Tom9811
Ja, das will er aber ja gerade nicht, weil im die while-Schleife anödet, was ich verstehen kann.

mich ödet das ja nicht an, ganz im gegenteil, ich würde das gern mit einer whileschleife machen.
aber die while schleife legt das ganze app lahm. wenn sich das app in der while schleife befindet, dann wird die notification nicht ausgelöst....

macuser · 4. August 2005, 10:33

Original von Tom9811
Negm-Awad

entschuldige bitte wenn ich das jetzt frage, ist das dein nachname?
ist nicht böse gemeint. ich möchte nur sicher gehen wen ich am telefon verlangen soll

Apfelbeisser · 4. August 2005, 10:33

@macuser: nein, das App wird nichtlahm gelegt, weil es über eigenes Thread läuft.
ja, es ist sein Nachname!

Amin Negm-Awad · 4. August 2005, 10:35

Nein, sie legt den Rechner nur insoweit lahm, als dass die Schleife Prozessorleistung verbraucht. Deine Haupt-App läuft normal weiter -- natürlich abzüglich der last des Threads.

Aber ich finde es schräg zu pollen, wenn du ein Ereignis bekommst. Event-driven ist ja eleganter und performanter. Da erübrigt sich eigentlich das Pollen.

Apfelbeisser · 4. August 2005, 10:41

Quellcode

+ (BOOL)setThreadPriority:(double)priority;

Mit dem kann man die Auslastung kontrollieren oder?
Der REchner wird nicht lahmgelegt, wenn jedenmals 1 Sekunde Pause eingelegt wird, oder?

Amin Negm-Awad · 4. August 2005, 11:03

Ah, ganz anders gemeint. Ich habe gerade mal mit ihm gesprochen. Die Lage stellt sich wie folgt dar:

Er schickt eine Anfrage an den Server. Hierauf bekommt er eine Antowrt. Anfrage und Antwort laufen über einen NSFileHandle, dem ein Comm-Kanal zugerondet ist.

Er will, dass seine App steht, bis die Anfrage bearbeitet ist. Vorher ist ein weiteres arbeiten nicht sinnvoll.

Damit dürften Threads genau das Verkehrte sein. Auch Notificatins, die ja für eine asynchrone Abarbeitung gedacht sind,sind genau falsch.

Er probiert jetzt einfach einen readDataToEndOfFile auf dem Kanal. Das klingt nämlich so, als ob die Lese-Reoutinen blocken würden. So lange hängt natürlich seine App -- was er ja gerade will.

Noch Ideen oder Verbesserungsvorschläge?

MCDan · 4. August 2005, 11:09

So, habe mir die Programme mal angeschaut.

Original von Tom9811
Nein, sie legt den Rechner nur insoweit lahm, als dass die Schleife Prozessorleistung verbraucht.

Nicht ganz. Im client wird die Action sendSQL: vom RunLoop getriggert, also dem Main Thread. Wenn dieser Thread jetzt auf das Ergebnis des Servers wartet ist natürlich die komplette Application "eingefroren", da der RunLoop beschäftigt ist.

In der Methode sendSQL: solltest Du einen neuen Thread starten, welcher dann parallel zum RunLoop läuft und so die Application nicht "einfrieren" lässt.

Wärend ich hier schreibe lese ich gerade, dass die Application wohl doch "einfrieren" soll, also überhaupt nicht mehr bedienbar sein soll, solange eine Verarbeitung läuft, richtig?

Amin Negm-Awad · 4. August 2005, 11:10

Ah, noch ein Problem und gleich die Lösung:

Weil readData... ja synchron ist, wartet deine App nicht nur, bis das EOF kommt, sondern ewig, wenn kein EOF kommt. Das wäre natürlich nicht wünschenswert. Du musst also die Notbremse ziehen können und das asynchron unterbrechen können. Hier eine Möglichkeit:

Du startest die Abfrage dann doch in einem eigenem Thread. Du machst dir hierzu ein kleines Objekt, welches als Init-Parameter den File-Handle bekommt und eine Methode -ready hat. Im Hauptprogramm kannst du dann eine while-Schleife machen, die dieses ready ständig abfragt. Wenn du nach einer Zeit t immer noch in der Schleife hängst, dann brichst du sie ab. Also in etwa

Quellcode

//Hauptthread
...
Thread erzeugen
Mit der Abfrage beauftragen
while( ![meinAbfrageManager ready] ) {
if( "time elapse" > 10 Sekunden )
break;
if( [meinAbfrageManager ready] )
// tue, was du tun musst
else
Thread töten
Fehlermeldung "Server schläft, ist überlastet, jedenfalls keine Antwort"
...

Alles anzeigen

So hast du eine synchrone Abfrage, die du asynchron stoppen kannst.

Amin Negm-Awad · 4. August 2005, 11:11

Er will, dass die App einschläft. Er hat lediglich das Problem, dass er dann die Notification nicht bekommt. Die benötigt er aber eben auch gar nicht.

Amin Negm-Awad · 4. August 2005, 11:12

Ja, ist es. Ich bin Halb-Ägypter. Das sieht man ja an den dunklen Haaren und Augen.

MCDan · 4. August 2005, 11:59

So, habe jetzt mal versucht im Client in einem eigenen Thread die Nachricht an den Server zu senden. Leider wird die Notification von NSFileHandle in den RunLoop gepostest, welcher jedoch schläft. Dies führt dann zu einem signal 5 (SIGTRAP).

Kannst Du mal versuchen die Kommunikation auf Distributed Objects mit NSConnection umzustellen?

Dann hättest Du laut Docu die Möglichkeit den RunLoop z.B. mit runMode:beforeDate: in den Mode NSConnectionReplyMode zu schalten. Dieser sollte dann auf ein Ergebnis von NSConnection warten.

Ist doch genau dass, was Du suchst, oder?

macuser · 4. August 2005, 12:04

Original von MCDan
So, habe jetzt mal versucht im Client in einem eigenen Thread die Nachricht an den Server zu senden. Leider wird die Notification von NSFileHandle in den RunLoop gepostest, welcher jedoch schläft. Dies führt dann zu einem signal 5 (SIGTRAP).

Kannst Du mal versuchen die Kommunikation auf Distributed Objects mit NSConnection umzustellen?

Dann hättest Du laut Docu die Möglichkeit den RunLoop z.B. mit runMode:beforeDate: in den Mode NSConnectionReplyMode zu schalten. Dieser sollte dann auf ein Ergebnis von NSConnection warten.

Ist doch genau dass, was Du suchst, oder?

*heul* alles nochmal machen *schnief*
aber man kann auch nur dazulernen.
gibts da ne vernünftige docu zu oder vllt sogar beispielcode? funktioniert das auch mit bonjour zusammen?

Amin Negm-Awad · 4. August 2005, 12:08

Klar wird ide Notification im Main-Thread gepostet. Ein Thread hat standardmäßig keine eigene Runloop.

Aber ich meine weterhin, dass er das nicht braucht. Notifications sind für asynchrone Beabreitung erforderlich. Er will synchron abarbeiten.

KLappt denn das readData... bzw. availableData nicht?

macuser · 4. August 2005, 12:23

Original von Tom9811
Klar wird ide Notification im Main-Thread gepostet. Ein Thread hat standardmäßig keine eigene Runloop.

Aber ich meine weterhin, dass er das nicht braucht. Notifications sind für asynchrone Beabreitung erforderlich. Er will synchron abarbeiten.

KLappt denn das readData... bzw. availableData nicht?

nein leider klappt es nicht

availableData bringt nicht den ganzen stream zurück
und readDataToEndOfFile bleibt hängen und friert die app wie in einer while schleife ein

Amin Negm-Awad · 4. August 2005, 12:35

Scheiße!

Bei availableData musst du natürlich eine Schleife machen. Du bekommst ja immer nur Häppchen.

Quellcode

NSData* häppchen;
NSMutableData* data = [NSMutableData data];
while( !(häppchen = [fileHandle availableData]) && ([häppchen length] > 0) ) {
[data appendData:häppchen];
}
// done