|
ENGLISH VERSION |
|
 |
| Links | | | Forum | | | Kommentare | | | News melden |
|
| Chat | | | Umfragen | | | Newsticker | | | Archiv |
|
| amiga-news.de Forum > Programmierung > filerequester task | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
| -1- 2 3 | [ - Beitrag schreiben - ] |
|
18.12.2011, 21:24 Uhr AGSzabo Posts: 1663 Nutzer |
Hallo, ich möchte mögliche Vorgehensweisen wie ein Filerequester, z.B. asl funktioniert wissen. Es muss ja erstmal irgendwie der aufrufenden Task zum schlafen gebracht werden, dessen Fenster muss einen Uhr-Mauszeiger bekommen, dann muss ein neuer Task oder Prozess für den Filerequester gestartet werden, der beim enden den Haupttask wieder aufweckt oder so. Wie könnte das im Detail vor sich gehen? Ich tippe mal, dass man ein Signalbit für den Haupttask braucht oder so. Ich bitte um Vorschläge. ags -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
18.12.2011, 21:31 Uhr Thore Posts: 2266 Nutzer |
Das Programm ruft den Requester auf und startet keinen eigenen Thread oder Task dafür. Damit wartet das Programm (automatisch) auf den Rücksprung dieses Unterprogramms. Es wird sozusagen "modal" gestartet. [ - Antworten - Zitieren - Direktlink - ] |
|
18.12.2011, 21:38 Uhr AGSzabo Posts: 1663 Nutzer |
Ich versteh das nicht. Ich möchte nicht asl verwenden sondern wissen wir dieses intern oder das Prinzip im allgemeinen funktioniert. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 18.12.2011 um 21:38 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
18.12.2011, 23:26 Uhr thomas Posts: 7718 Nutzer |
Was gibt es denn da zu verstehen? Du hast doch ein Hauptprogramm, das die IDCMP-Nachrichten von deinem Hauptfenster behandelt. Wenn dieses Hauprogramm jetzt die Nachricht bekommt, dass der "Dateiauswahl"-Knopf gedrückt wurde, dann springst du von dort einfach in das Unterprogramm, das den Datei-Requester anzeigt. Das Unterprogramm öffnet ein Fenster mit einer Dateiliste, zwei Eingabefeldern und ein paar Knöpfen. Dann sorgst du dafür, dass sich das alles richtig bewegt, wenn der Benutzer drin rumklickt. Wie man eine GUI programmiert, weißt du ja, nehme ich an. Wenn der Benutzer auf Ok oder Cancel klickt, machst du das Fenster wieder zu und springst zurück zum Hauptprogramm. Das war's. Solange du im Unterprogramm bist, reagiert das Hauptfenster nicht mehr auf Eingaben, einfach weil keiner sie behandelt. Einziger Haken ist, dass Intuition die Eingaben natürlich nicht vergisst, sondern dass sie bei der Rückkehr vom Dateirequester alle auf dem UserPort des Hauptfensters stehen. Es gibt zwei Möglichkeiten, das zu behandeln: entweder du überliest nach der Rückkehr einfach alle IDCMP-Nachrichten, die anstehen. Oder du sorgst vorher dafür, dass du keine bekommst. Das geht mit ModifyIDCMP. Den Mauszeiger kannst du mit SetWindowPointer(window, WA_BusyPointer, TRUE, TAG_END) bzw. ..., FALSE, ... setzen. -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ Dieser Beitrag wurde von thomas am 18.12.2011 um 23:30 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
19.12.2011, 16:07 Uhr Holger Posts: 8116 Nutzer |
Zitat:Die asl.library benutzt denselben IDCMP für den Dateirequester wie das Fenster, das geblockt wird. Daraus ergibt sich Möglichkeit 3: solange der Requester offen ist, alle Messages für andere Fenster ignorieren. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
19.12.2011, 16:26 Uhr AGSzabo Posts: 1663 Nutzer |
@Holger: Woher weiss asl welches Fenster ignoriert werden soll, bzw woher kennt es dessen idcmp? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
19.12.2011, 17:31 Uhr Thore Posts: 2266 Nutzer |
Das weiß asl nicht, aber dein Programm, welches asl aufruft. Ich schlage vor Du liest die Includes&Autodocs vom RKM durch  Das Fenster wird auch nicht wirklich blockiert, sondern richtiger: asl wird ausgeführt. Damit bleibt der Rest des Programms stehen -> Unterprogramm-Aufruf, wobei das Haiptprogramm auf den Rücksprung wartet. Lediglich Messages könnten gequeued werden, oder nebenherlaufende Threads können weiterlaufen. Ein asl Aufruf ist ein ganz normaler Lib Call, auf den das Programm warten muss. [ - Antworten - Zitieren - Direktlink - ] |
|
19.12.2011, 19:02 Uhr AGSzabo Posts: 1663 Nutzer |
@Thore: Also ich zumindest gebe dem asl beim Aufruf weder einen Zeiger auf meinen IDCMP noch einen auf mein Fenster an. Es geht trotzdem. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
19.12.2011, 22:12 Uhr Thore Posts: 2266 Nutzer |
Du gibst entweder ein Window an, oder nichts. Gibst du mit ASL_Window ein Fenster an, wird auch der IDCMP Port des Windows für das ASL Requester verwendet. Hier findest du auch was darüber http://amigadev.elowar.com/read/ADCD_2.1/AmigaMail_Vol2_guide/node0016.html [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 19:55 Uhr AGSzabo Posts: 1663 Nutzer |
Kann es sein, dass ein simpler Task mit AddTask() nicht ausreicht um dos funktionen daraus aufrufen zu können? ich möchte lediglich ein directory einlesen mit Lock/CurrentDir/Examine/ExNext -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 21.12.2011 um 20:01 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 20:05 Uhr thomas Posts: 7718 Nutzer |
@AGSzabo: Genau das ist der Unterschied zwischen Tasks und Prozessen: aus Prozessen kannst du DOS-Funktionen aufrufen, aus Tasks heraus nicht. Warum willst du einen zweiten Task starten? Haben wir dir nicht dargelegt, dass du das nicht brauchst? -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 20:21 Uhr Thore Posts: 2266 Nutzer |
Wozu muss ein Directory Einlesen in einem separaten Prozess oder Task stattfinden? Da die Dauer des Einlesens sehr varrieren kann, und dein Hauptprogramm vermutlich die Liste verwalten soll, muss es eh auf die Liste warten. Ich finde ein simples Unterprogramm ist hierfür die bessere Lösung. Oder hast Du andere Ideen warum Du es als Task oder Prozess laufen lassen willst? [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 20:24 Uhr AGSzabo Posts: 1663 Nutzer |
@thomas: Ich will nicht asl nutzen - mich interessiert daran nur wie asl es macht - sondern mit meinem GUI einen eigenen FileRequester programmieren. Ich habe gerade die autodocs zu CreateNewProc() durchgelesen. Das scheint das zu sein was ich brauche. Jedoch war es bei dem AddTask() vorteilhaft, dass ich vor dem Starten des Task den Zeiger auf meine Variablen da blos in TC_Userdata schreiben musste und schon hatte der Task Zugriff darauf. Bei CreateNewProc() ginge das auch, allerdings nur wenn der Process schon gestartet ist. Also fail. Jetzt hab ich mir überlegt, dem Process eine Message mit dem Pointer zu schicken und den als erstes darauf warten zu lassen. Mir ist noch nicht klar wie das geht. Und muss ich dazu einen reply-port einrichten? @Thore > Oder hast Du andere Ideen warum Du es als Task oder Prozess laufen lassen willst? Echtzeit? Abbruchmöglichkeit? Das mit dem Unterprogramm überlege ich mir noch. Was meinst Du mit "Auf die Liste warten"? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 21.12.2011 um 20:32 Uhr geändert. ] [ Dieser Beitrag wurde von AGSzabo am 21.12.2011 um 20:33 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 20:44 Uhr thomas Posts: 7718 Nutzer |
Zitat: Du interessierst dich dafür, wie ASL es macht, damit du es anders machen kannst, oder wie? ASL benutzt keine eigene Task, es läuft in der Task des rufenden Programms. -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 20:49 Uhr AGSzabo Posts: 1663 Nutzer |
@thomas: Sinn ist es, die verschiedenen Möglichkeiten zu beleuchten und sich dann zu entscheiden. Ich weiss nicht ob ASL beim Laden des dirs die Listview nach jedem gelesenen Eintrag refresht. Imo nein, es sieht asynchron aus. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 21:19 Uhr Thore Posts: 2266 Nutzer |
> Echtzeit? Abbruchmöglichkeit? Das mit dem Unterprogramm überlege ich mir noch. Was meinst Du mit "Auf die Liste warten"? Das Datei-Einlesen geht in einer Schleife. In genau dieser Schleife machst Du eine Event-Abfrage ob z.B. Abbruch gedrückt wurde oder das Verzeichnis gewechselt wurde. (Normalerweise ob ein Event stattfand, und wenn ja wird ausgewertet welches Event es war) Dann musst du nicht mehr auf die ganze Liste warten. Es kommt ja immer drauf an was man machen will. In diesem Fall springst Du einfach aus der Schleife und dein Programm macht woanders weiter, z.B. das Fenster schließen oder das Verzeichnis wechseln, oder das ausgewählte File übergeben. [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 21:23 Uhr AGSzabo Posts: 1663 Nutzer |
@Thore: > In genau dieser Schleife machst Du eine Event-Abfrage ob z.B. Abbruch gedrückt wurde oder das Verzeichnis gewechselt wurde. Wie denn wenn das drücken von Abbruch nur geht wenn der (haupt)prozess frei ist um das GUI zu machen. Das Event kann beim mir nur durch einen Hook am Button erfahren werden. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 21:40 Uhr Thore Posts: 2266 Nutzer |
Ah... ich beginne dein Problem zu verstehen. Ich nehm an du verwendest deine eigene GUI die Du mal programmiert hast, und die Main Loop verwaltet alles. Ein Unterprogramm würde die Main Loop verlassen und damit eine Reaktion dort nicht mehr möglich machen. Dann musst Du einen anderen Ansatz finden. Gibts keinen "GUI-Master" der über alles wacht und losgelöst vom Hauptprogramm ist? [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 21:43 Uhr AGSzabo Posts: 1663 Nutzer |
@Thore: Gibts nicht, weil ich das in 90% der Fälle nicht gebraucht habe, bzw beim erstellen des eigenen GUI noch garnicht soweit gedacht hatte. Jetzt alles umzustellen weiß ich nicht ob das geht. Da ich mit Hooks arbeite, würde der GUI Task diese doch auch bloß aufrufen können? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 21.12.2011 um 21:44 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
21.12.2011, 22:40 Uhr Thore Posts: 2266 Nutzer |
Hmm es gibt aber noch PopUps, Alert Requester, Info-Requester, so modales Zeug eben die die Hauptapplikation blockieren können und dürfen. Und eben Filerequester/Screenrequester/Fontrequester gehören dazu. Jetzt heißts grübeln Vll fällt jemand was ein, es in das Konzept mit aufzunehmen.[ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 09:41 Uhr AGSzabo Posts: 1663 Nutzer |
@Thore: Es liegt in der Natur meines GUIs, dass wenn der Requester die Hauptapplikation blokiert, dass er dann auch selber nimmer funktioniert. Es gibt eine Master Wait/GetMsg Routine in der Application Klasse. Das Hauptprogramm geht da rein (Methode) und kehrt erst zurück wenn irgendjemand (Hook an Button zB) von da drinnen aus die Methode Quit aufgerufen hat (die setzt ein Quit-Flag). Diese zentrale Wait/GetMsg Routine arbeitet für alle Fenster, die aus dem Hauptprogramm aus geöffnet werden, also auch für das Filerequester-Fenster. Das einzige was kurz blocken dürfte, wäre das einlesen eines Dirs, das geht heutzutage ja in der Regel sehr schnell. Popups blockieren bei mir nicht wirklich, sie können fast (?) alle Elemente beinhalten, die auch ein Fenster beinhalten kann. -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 22.12.2011 um 09:44 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 16:12 Uhr Holger Posts: 8116 Nutzer |
Man kann ganz einfach asynchrone I/O benutzen, d.h. statt DOS-Funktionen aufzurufen, die eine Message an das Dateisystem schicken und auf die Antwort warten, schickt man selber eine Message an das Dateisystem und kehrt zur Hauptschleife zurück. Diese muss natürlich wissen, dass es außer GUI-Events auch noch andere Messages gibt, um die man sich kümmern muss (Abholen, Eintrag/Einträge der Dateiliste hinzufügen, weitere Anfordern), aber das muss sie ja sowieso, auch dann, wenn man einen Sub-Task/Prozess anlegt. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 21:08 Uhr Der_Wanderer Posts: 1229 Nutzer |
Es gibt eine goldene Regel die da heißt: "Never block the main thread!" Wenn ein Popup oder Auswahl Requester modal sein soll, dann setze für die anderen Fenster den Busy Pointer, wie thomas gesagt hat: SetWindowPointer(window, WA_BusyPointer, TRUE, TAG_END) Dann kann der Main Thread immer noch reagieren, z.B. auf Dinge wie Iconify oder eben andere Background Aufgaben weiterhin erledigen. In eine Unterroutine springen und damit den Eigentlichen Message Loop verlassen ist ziemlich old-school und nicht sehr elegant, zumal man Code duplizieren muss, was eigentlich immer schlecht ist. Den ListView würde ich als im ganz normalen Message Loop verwalten. Dazu würde ich dann einen Worker-Thread starten, der das Dateisystem scannt und den ListView befüttert. Das ganze muss natürlich "threadsafe" passieren, was einiger programmier Erfahrung bedarf, aber natürlich immer eine gute Idee ist, wenn deine Engine multithreading unterstützt. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 22.12.2011 um 21:16 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 21:18 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Daher die Frage, wie ich dem Scan Process den Pointer auf die Listview mitgeben kann. Beim Task war das ja einfach in TC_Userdata ... -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 21:25 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Diese Threadsicherheit muss ich mir noch überlegen. Wie erreiche ich, dass der scan task nicht gerade ein item der listview hinzufügt und der guitask derweil schonmal zeichen was noch nicht ganz da ist? es reicht ja nicht, das item nur hinzu zu fügen, es muss auch das layout neu berechnet werden, scroller anpassen und so. der gui task könnte noch mit dem letzten zeichnen beschäftigt sein, während der dir task noch das layout für ein item mehr berechnet (in der AddItem methode der listview)... -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 22.12.2011 um 21:38 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 21:56 Uhr Der_Wanderer Posts: 1229 Nutzer |
Das einfachste, um es Threadsafe zu bekommen ist, den Zugriff auf die Liste durch Semaphoren zu regeln. D.h. während gezeichnet wird, muss der Scann-Thread warten. Wenn er dann wieder "dran kommt", locked er die Semaphore und fügt seine bisher eingelesenen Einträge hinein und released wieder. Solange kann dann nicht refreshed werden. Da das Hinzufügen in die Liste aber vermutlich sehr schnell geht, ist das kein Problem. Langsam, bzw. nicht vorhersehbar wie lange das dauert, ist das Scannen des Verzeichnisses, was dann aber die GUI nicht beeinträchtigt, selbst wenn es mal 10sec hängt (ja, bei Netzlaufwerken, WinUAE oder Disketten kann sowas schon mal eine Weile dauern...) Wenn der Scann Thread "AttemptSempahore" nutzt, dann muss er nicht warten wenn die GUI gerade nue-zeichnet, sondern liesst dann eben den nächsten Eintrag, solange bis die GUI fertig ist. Dann fügt er seine Einträge hinzu und stößt einen Refresh an. Somit wird die Rechenleistung optimal ausgenutzt. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 22:07 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Hmm, list dich gut aus aber ich kann noch nich sagen dass ich es voll verstanden hätte. Der Scan thread muss mit dem befüllen warten während gezeichnet wird, darf aber währenddessen schonmal lesen? So könnte man das warten in die befüll-routine implementieren, also libraryseitig klären? Muss nun der Scan Task mit dem befüllen so warten solanbge gezeichnet wird, oder der Gui task mit dem Zeichnen warten solange befüllt wird? ps: wieso semafore und nicht signale? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 22.12.2011 um 22:10 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 22:11 Uhr Der_Wanderer Posts: 1229 Nutzer |
Zitat:Beides. Siehe auch http://de.wikipedia.org/wiki/Semaphor_(Informatik) Was der Scan Task aber nicht muss ist warten mit dem Lesen des Directories, und das ist der Flaschenhals. So bekommst du optimale Füllgeschwindigkeit und jedesmal ein Refresh, wenn sich was getan hat. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ Dieser Beitrag wurde von Der_Wanderer am 22.12.2011 um 22:12 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 22:24 Uhr AGSzabo Posts: 1663 Nutzer |
@Der_Wanderer: Ist dieses das was du mit Listview locken gemeint hast? Sollte ich das Semaphor in die Listview klasse implementieren oder wohin? ps: hmmm, ich könnte den gui Task alles andere zeichnen lassen, aber nicht die Listview während die gelockt ist ... (?) pps: ich könnte es in das GUI system selbst implementieren, einfach jedem (!) objekt in der root klasse die möglichkeit geben gelockt zu werden. dazu muss wohl ein name für das objekt her, oder? udn noch dazu einer, der systemweit (auch der rest vom OS und andere Programme) einzigartig ist? -- Sam mini os4.1 upd. 2 / e-uae 39bb2 / A4000D 3.0 & 3.9 2mbchip 8mbfast Ariadne_II ide DVD und HD / A500 3.1 (mkick) adide 50mb / Athlon ii X2 Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 22.12.2011 um 22:28 Uhr geändert. ] [ Dieser Beitrag wurde von AGSzabo am 22.12.2011 um 22:34 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
22.12.2011, 22:41 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ja genau. Zur Einfachheit würde es aber auch schon ausreichen, für die Engine-Instanz Global ein "lock" einzubauen. Sooo viele Requester hat man ja in einem Programm normalerweise nicht offen, als dass sich das spürbar auswirken würde. Zu dem Lock: Der GUI Thread sollte ein "ObtainSemaphore" machen, also wirklich blockieren bis er die Semaphore bekommt. Was halb-fertiges zeichnen macht auch keinen Sinn und würde zu viel Logik erfordern (und damit potentielle Bugs). Die Semaphore kannst du je generell vor jedem Zeichenvorgang holen, so hast du den Mechanismus nicht nur für dein Listview sondern für alle Widgets. Der Scan-Thread *könnte* auch ein ObtainSemaphore machen, allerdings stellt sich dann die Frage, wann soll er das machen. Wenn er das nach jedem Directory Eintrag machen würde, dann würde es jedesmal ein Refresh geben und ein weiterer Eintrag würde gescannt. In dem Fall ist das super langsam und man könnte das auch single Threaded machen. Also macht du kein ObtainSempahore, sondern AttemptSemaphore. Das blockiert nicht,wenn die Semaphore gerade besetzt ist. Wenn du die dann nicht bekommst, darfst du natürlich nichts in den Listview hängen, da er gerade zeichnet. Aber du kannst ruhig weiter dein Directory lesen und den Eintrag erstmal lokal merken. Sobald der Scan Thread dann "dran darf", also per AttemptSema die Sempahore bekommt, kann er alles, was sich aufgestaut hat, auf einen Rutsch in das Listview hängen, dann die Semaphore wieder Releasen und ein Refresh anstoßen, und dann weiterackern. Wird der ListView zwischenzeitlich freigegeben, dann beendet sich der Scan-Thread einfach. Deshalb darf er sich nichts über das ListView merken ausserhalb des Attempt-Release Blocks. (z.b. den Pointer drauf. Den muss er sich immer wieder neu besorgen. Wie er das macht, hängt von deinem GUI Toolkit ab. Du könntest den Task auch explitzit beenden, indem du ihm ein Signal schickst, auf das er horcht. CTRL+C bietet sich in dem Fall eigenlich immer an. -- -- Author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Antworten - Zitieren - Direktlink - ] |
| -1- 2 3 | [ - Beitrag schreiben - ] |
| amiga-news.de Forum > Programmierung > filerequester task | [ - Suche - Neue Beiträge - Registrieren - Login - ] |
|
|
Impressum |
Datenschutzerklärung |
Netiquette |
Werbung |
Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten. |
|