|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Programmierung > zeiger auf globale an prozess übergeben | [ - Search - New posts - Register - Login - ] |
| -1- 2 | [ - Post reply - ] |
|
2009-11-15, 15:58 h AGSzabo Posts: 1663 User |
ich rätsele grade rum was wohl die gängigste methode sei, um den zeiger auf die globalen variablen von einem parent-prozess an einen neuen prozess (CreateNewProc) zu übergeben. spontan fallen mir zwei methoden ein: - forbid, dann createnewproc, dann *globals nach TC_userdata, dann permit - prozess starten, der prozess wartet auf eine msg an seinem port, der parenttask sendet ihm eine message mit den nötigen zeigern. ich kann mich nicht entscheiden. gibts vielleicht noch ne bessere methode? vielleicht über das ExitData tag? -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-15, 17:11 h RhoSigma Posts: 67 User |
Hallo, also wenn ich globale Variablen, Zeiger etc. mit mehreren Prozessen teilen muss, habe ich mir angewöhnt, dafür eine Struktur zu definieren, die alle nötigen Sachen enthält. Anfangen tut diese Struktur immer mit einer SignalSemaphore, hinter der dann meine privaten Zeiger und Variablen folgen. Diese Semaphore (mit meinen daranhängenden Daten) wird dann in die systemweite Semaphore-Liste eingebunden, und ist somit via FindSemaphore() für jeden zweit, dritt u.s.w Prozess erreichbar. Außerdem hat man mit den Funktionen Obtain-/ReleaseSemaphore() auch gleich eine Methode um die Zugriffe aller beteiligten Prozesse zu koordinieren. CAprefs und XpkMasterPrefs pflanzen z.B. auch einfach eine Semaphore ins System mit den daranhängenden Einstellungen. Somit können dann bei Xpk z.B. einfach alle sub-libs nach der Semaphore suchen und finden da ihre aktuellen Einstellungen. Was ich damit sagen will ist, das IMHO diese Methode eigentlich der Standard sein sollte, wenn Daten jeglicher Art global verfügbar gemacht werden sollen. Grüße, RhoSigma [ Dieser Beitrag wurde von RhoSigma am 15.11.2009 um 17:17 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2009-11-15, 17:16 h AGSzabo Posts: 1663 User |
@RhoSigma: wow. sowas hab ich noch nie gemacht, aber mich gewundert was semaforen sind... ist komplett neu für mich, ich seh gleich mal nach was ich dazu an infos finden kann... -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-15, 17:32 h AGSzabo Posts: 1663 User |
@RhoSigma: hmmm.. in meinem fall scheint die methode über semafore ungeeignet, weil es mehrere instanzen der kommunizierenden processe geben kann. proc a startet proc b und übergibt daten an proc b. wenn ich das über eine semafore mache, kann es nicht mehrere dieser paare geben. jedes paart müsste sich auf einen privaten schlüssel (name) verständigen, sonst kauen alle prozesse an den selben daten. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-15, 19:28 h thomas Posts: 7718 User |
@AGSzabo:Zitat: Du solltest dich mal einigen, was du willst. Du überschreibst den Thread mit "globale Variablen übergeben", aber wenn dir jemand sagt, wie man es machen könnte, ist dir das zu global und du hättest es doch lieber lokal ? Globale Variablen sind die, auf die alle Unterprogramme und Unterprozesse zugreifen können. Natürlich "kauen" da alle Prozesse dran. Dafür ist der Semaphore ja da, um die Zugriffe zu serialisieren. Für die Parameterübergabe an einen neuen Prozess benutzt man die zweite von dir vorgeschlagene Methode, also die Message. Wenn man einen asynchronen Prozess startet, der seine Verarbeitung durchführt, und dann eine Antwort liefert, schickt man die Message ab und vergißt sie erstmal. Wenn die Verarbeitung beendet ist, schickt der Prozess die gleiche Message mit der Antwort zurück (ReplyMsg). Wenn der neue Prozess eher eine Art Server ist, der nacheinander mehrere Augaben bekommt und so lange am Leben bleibt, bis er das Kommando zum Beenden bekommt, dann schickt man ihm die initiale Message und wartet auf die Antwort, daß der Server bereit ist. Dann kann man ihm weitere Messages mit den Aufgaben schicken, die er jeweils beantwortet, sobald die Aufgabe durchgeführt wurde. Gruß Thomas -- Email: thomas-rapp@web.de Home: thomas-rapp.homepage.t-online.de/ [ - Answer - Quote - Direct link - ] |
|
2009-11-15, 20:10 h AGSzabo Posts: 1663 User |
@thomas: > global und du hättest es doch lieber lokal ? wohl eher sub-global. lokale variablen kennt maximal 1 prozess. ist aber streitsache. > Für die Parameterübergabe an einen neuen Prozess benutzt man die zweite von dir vorgeschlagene Methode, also die Message. ok, zu dem schluss bin ich auch gekommen. allerdings sollte ich zum empfang der antwort einen eigenen temporären port anlegen weil der port den ich schon habe ja die intuimessages der fenster erhält und da würde was durcheinander kommen. in meinem fall braucht der parent-prozess nach dem absenden der message blos am replyport zu warten, bis der unterprozess fertig ist, denn die "aufgabe" benötigt 'einen reinen tisch' sprich einen neuen prozess. noch eine frage die hierher passt: kann ein task (nicht ein prozess!) funktionen der doslibrary benutzen, also zB ein verzeichnis einlesen? gedacht für asynchrones laden des verzeichnisinhaltes, so dass das gui clickbar bleibt. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 15.11.2009 um 20:26 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2009-11-15, 20:38 h ZeroG Posts: 1487 User |
@AGSzabo: DOS-Funktionen die Dateizugriffe mit sich bringen müssen zwingend in einem Prozess laufen. Das sind praktisch alle, Ausnahmen sind extra in dem Autodoc angeben. Grundsätzlich würde ich immer einen Prozess anstatt einem Task verwenden, auf die paar Byte Speicher kommts nicht an... [ - Answer - Quote - Direct link - ] |
|
2009-11-15, 23:46 h Holger Posts: 8116 User |
Zitat:Jeder Prozess besitzt bereits einen Port in seiner Prozess-Struktur. Den kannst Du nicht für intui-Messages benutzen, aber wenn Du an diesem Port eine Startup-Message empfängst, bevor Du irgendeine DOS-Funktion aufrufst, funktioniert das problemlos. Genau so funktioniert der Startup bei Programmen, die von der Workbench gestartet werden. Zitat:Ein Task kann seit AmigaOS 2.0 die meisten DOS-Funktionen benutzen, das ist aber äußerst ineffizient, weil dann jedes Mal ein temporärer MessagePort erzeugt werden muss, weil eben jener oben beschriebene Port in der Prozess-Struktur fehlt. Du kannst es umgekehrt machen: ein Task sorgt dafür, dass das GUI reagiert, denn dafür braucht man keinen Prozess. Und der parent Prozess liest das Verzeichnis ein. Allerdings brauchst Du ja sowieso einen MessagePort, wenn Du wie beschrieben Variablen übergeben willst, also erzeug doch einfach einen Prozess statt Task. Oder kommuniziere statt mit einem Sub-Prozess gleich mit dem Dateisystem über DOS-Packets, das sind auch nur Messages mit einem bestimmten Aufbau. Dann sparst Du Dir den zusätzlichen Task/Prozess. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2009-11-16, 08:30 h AGSzabo Posts: 1663 User |
@Holger: > Jeder Prozess besitzt bereits einen Port in seiner Prozess-Struktur. Den kannst Du nicht für intui-Messages benutzen, aber wenn Du an diesem Port eine Startup-Message empfängst, bevor Du irgendeine DOS-Funktion aufrufst, funktioniert das problemlos. ok, der neu gestartete prozess empfängt die variablen per msg an seinen port (die addresse erhalte ich aus dem zeiger auf den prozess den CreateNewProc() zurückliefert). aber die rückwantwort, kann die an den process-port des parent-prozesses gehen (der schon dos funktionenen aufgerufen hat) oder muss ich extra einen replyport einrichten? eigentlich brauche ich keine antwort, muss nur warten bis der prozess fertig ist ... also reicht ein signal? -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 16.11.2009 um 08:41 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2009-11-16, 09:04 h RhoSigma Posts: 67 User |
Zitat: Klar kann die Antwort an den parent gehen, und wenn mehrere Msg dort ankommen (z.B. von DOS-Operationen), dann must du nur deine Msg entsprechend identifizieren (z.B. mit ID versehen). Die Antwort MUSS aber auf alle faelle geschickt werden, damit dein parent weiss, aha die Msg ist erledigt und kann frigegeben werden. Andernfalls bekommst du spaetestens wenn der parent beendet probleme, im schlimmsten Fall ein Speicherleck. [ - Answer - Quote - Direct link - ] |
|
2009-11-16, 10:10 h AGSzabo Posts: 1663 User |
@RhoSigma: ich dachte, der neue prozess darf die message selber freigeben? ich weis ja was ich tue weil alles meins ist. das mit der ID bedeutet ich muss die messages am parent port durchsuchen? ...und dann wieder warten, bis eien neue msg ankommt ... dann wieder suchen..? -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-16, 10:39 h RhoSigma Posts: 67 User |
Zitat: Natuerlich, wenn du weist, das die Msg nach senden an den neuen Prozess erledigt ist, da dieser die Msg dann gleich freigibt ist das OK, hauptsache DU denkst dann auch daran und programmierst nicht am ende des parent prozesses auch noch mal ne Freigabe :-) Generell ist und bleibt das aber trotzdem schlechter Programmierstil, man sollte besser die vorgegeben Funktionsweisen des Message-Systems einhalten, und das heisst ganz einfach, das der Prozess, der die Msg erstellt, sie auch wieder freigibt. Um zu wissen wann das geht muss er auf die Beantwortung der Msg durch den neuen Prozess warten. Zitat: Ja, wenn dir das zu umstaendlich ist, dann definiere eben einen anderen MsgPort dafuer, der dann nur auf die Antwort wartet. Ist ja kein Problem mit mehrern MsgPorts zu arbeiten, du must nur wissen welche Msg wo ankommt. [ - Answer - Quote - Direct link - ] |
|
2009-11-16, 12:07 h Holger Posts: 8116 User |
Zitat:Es ist nicht so wichtig, ob Du schon mal DOS Funktionen aufgerufen hast. Wichtig ist, ob in der Zeit, in der die Message ankommen könnte, DOS Funktionen aufgerufen werden. DOS Funktionen sind in sich abgeschlossen, sie verschicken Nachrichten und kommen erst zurück, wenn die Antworten angekommen sind. Sie verkraften es aber nicht, wenn währenddessen Nachrichten ankommen, mit denen sie nichts anfangen können. Zitat:Nur wenn Du exakt einen Kind-Prozess hast. Andernfalls kannst Du nicht erkennen, wer das Signal geschickt hat. Es können sogar mehrere Prozesse gleichzeitig ein Signal auslösen, und Dein parent registriert das nur einmal. Zitat:DOS Funktionen wissen aber nichts von Deinen IDs. Das funktioniert nur, wenn Du die Kommunikation mit den Dateisystemen komplett selbst abwickelst und keine DOS Funktionen aufrufst. Zitat:Beim AmigaOS geht das. Du solltest diese Zuständigkeit der Freigabe aber gut dokumentieren. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2009-11-16, 12:12 h AGSzabo Posts: 1663 User |
@Holger: > Wichtig ist, ob in der Zeit, in der die Message ankommen könnte, DOS Funktionen aufgerufen werden. garantiert nicht, denn der parent prozess macht nach dem absenden der 'startup"-message nie und nichts anderes als auf diese message zu warten dass sie zurück kommt. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 16.11.2009 um 12:13 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2009-11-16, 12:53 h Holger Posts: 8116 User |
Zitat:Dann kannst Du natürlich den Prozess-MessagePort benutzen. Aber wozu dann eigentlich den zweiten Prozess? -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2009-11-16, 14:09 h AGSzabo Posts: 1663 User |
@holger wenn ich will, dass DoMethod(selectfile) erst zurück kommt wenn ein file ausgewählt wurde (wie asl), geht da zwischendurch das gui des parent prozesses nicht und kann auch nicht vom unterprozess genutzt werden, sondern letzterer braucht einen eigenen prozess der sein eigenes gui (den filrequester) öffnet und durch die masterlibrary handhabt. das parent-gui bleibt derweil taub, man könnte den mauszeiger der parent windows auf DIE UHR setzen. wenn ich DoMethod(selectfile) sofort zurückkommen lasse, brauche ich einen OK-hook im requester, während der requester sein fenster an die fensterliste des app-objects anhängt, damit es beim beenden automatisch geschlossem werden kann und damit es bei gui-configurations-änderungen die meldung bekommen kann sich anzupassen. außerdem erfrägt das fenster des requesters bei der rückkehr variante vom app-object den mit den anderen fenstern gemeinsamen msgport, so dass auch das parent gui clickbar bleibt während der filerequester offen ist. dabei kann es evtl zu komplikationen kommen, die ich im moment nicht absehen kann. mfg Andreas -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 16.11.2009 um 14:13 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2009-11-17, 12:10 h Holger Posts: 8116 User |
Zitat:Ich kann jetzt nicht wirklich erkennen, was Du überhaupt erreichen willst, aber ich versichere Dir: die Logik eines Programms, das ein Unterprogramm aufruft, unterscheidet sich durch nichts von der Logik eines Programms, das einen neuen Prozess startet und dann ausschließlich auf die Beendigung des neuen Prozess wartet. Letzteres ist nur komplizierter zu programmieren. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 03:54 h AGSzabo Posts: 1663 User |
@Holger: die logik scheint die selbe zu sein aber mein haupt-task ist schon 'verstopft'. du gehts auch nicht von einer unterroutiene aus nochmal rekursiv in die haput-wait-msg-schleife? -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 09:45 h DrNOP Posts: 4118 User |
Jetzt wird's hier aber ganz wild. Kannst du dich mal von der Implementierung lösen und dein Problem abstrakt durchdenken? Mit einem Hauptprogramm, das ein Unterprogramm aufruft, das das Hauptprogramm aufruft, wirst du niemals auf einen grünen Zweig kommen! -- Signaturen mit mehr als zwei Zeilen gehen mir auf den Wecker [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 10:18 h AGSzabo Posts: 1663 User |
@DrNOP: > Mit einem Hauptprogramm, das ein Unterprogramm aufruft, das das Hauptprogramm aufruft, wirst du niemals auf einen grünen Zweig kommen! daher brauche ich für das unterprogramm einen eigenen prozess mit seinem eigenen quit-flag u.a., das war die frage warum es so ist. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 10:29 h AGSzabo Posts: 1663 User |
@RhoSigma: >XpkMasterPrefs pflanzen z.B. auch einfach eine Semaphore ins System mit den daranhängenden Einstellungen. was hindert dieses system daran die globalen aus der xpk-base zu lesen? -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 11:28 h Thore Posts: 2266 User |
Was genau möchtest du denn machen? Semaphoren sind, soweit ich das alles hier mitverfolgt hab, eine vernünftige Lösung. Darf der ChildProcess die Variablen ändern oder nur als Konstanten sehen? Was möchtest du denn machen? Vielleicht gibts eine einfache Lösung für das Problem. [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 12:16 h AGSzabo Posts: 1663 User |
@Thore: der haupttask ist der welcher als erstes gestartet wurde. der managt auch das gui, also wenn das programm beschäftigt ist, geht das gui nicht. wenn ich will, dass der haupttask erst aus der filerequester-funktion zurück kehrt wenn ok oder cancel geclickt wird, geht derweil das gui nicht. daher braucht der requester sein eigenes gui und dazu einen eigenen prozess. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 13:04 h Thore Posts: 2266 User |
Möchtest Du daß der Haupttask blockiert wird, also der Requester sozusagen Modal ist? Dann muss der Haupttask einfach auf die Schließung des Fensters warten, das kannst Du z.B. mit Messages machen (Signale), der MessageHandler wartet dann eben auf das entsprechende Signal. Der Childtask kennt ja seinen Haupttask (kannst du ihm auch mitgeben) und kann dann auf diesen Task das Signal setzen. Oder willst Du daß das Fenster nicht modal ist, sozusagen Barrierefrei im Haupttask die Gui bedienbar bleibt. Dann kannst Du das ebenfalls mit dem MessageHandler regeln, welcher die anderen Events ebenfalls abfragt. Ich hab mich jetzt nicht in dein Programm eingelesen und weiß daher auch nicht welches die günstigere Variante ist, das hier ist daher nur ein Beispiel... es gibt mehrere Wege die nach Rom führen =) [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 13:18 h AGSzabo Posts: 1663 User |
@Thore: auf jeden fall gibt es mehr wege. mir erscheint die lösung mit dem neunen prozess der eine message mit den subglobalen zeigern bekommt am einfachsten und passendsten. ob ich auf ein signal warte oder auf die rückker meiner message... -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 13:50 h Thore Posts: 2266 User |
Du kannst auch einen Context erzeugen. Der Context könnte dann die Thread-IDs und die Variablen beherbergen. So brauchst du keine globale Variable und es ist sicher, da für jedes geöffnete Fenster sowas neu erzeugt wird. Im Grunde ist es nur eine Klasse oder eine Struktur die neu erzeugt wird, und nach der Arbeit wieder freigegeben werden kann, und einen Bezug zwischen den Programmteilen darstellt. Das wäre dann die "Handarbeit". [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 14:41 h AGSzabo Posts: 1663 User |
@Thore: ich verstehe das zwar nicht was du da beschreibst aber ich habe schon sowas wie ein "context" object. es heisst "buffer" und beherbergt variablen, die den unterobjekten gemeinsam sind. im falle filerequester ist das filerequester-objekt zugleich der buffer für seine childs (aus denen er aufgebaut ist). da darf mit fixen offsets gearbeitet werden solanage man in der filerequesterklasse intern bleibt. -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 18.11.2009 um 14:43 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 16:43 h Thore Posts: 2266 User |
Ja das wäre sowas in der Art, gleiches Prinzip, ähnlich angewendet [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 16:49 h AGSzabo Posts: 1663 User |
@Thore: nur müsste der neue task irgendwie den zeiger auf den "buffer" bekommen und dazu brauch ich ich dann wieder die message. da könnte die message gleich alles nötige selbst enthalten: den zeiger auf die xuibase und den zeiger auf das filerequester-objekt. das reicht. wobei der neue prozess die xuibase auch durch selber öffen der openxui.library bekommen könnte, bleibt also gerademal EIN zeiger. Und weil es blos einer ist, dachte ich, ich könnte den evtl über das Tag (für CreateNewProc) "ExitData" setzen. Das feld ist zwar für was anderes gedacht aber ich denke es stört niemand wenn ich es als user-data verwende... und einene zugehörigen exitcode hab ich auch nicht. den zeiger würde der neue prozess dann in seinem pr_ExitData feld auslesen können. der zeiger könnte auber auch auf einen buffer zeigen, in dem dann auch der xuibase-pointer drin ist... -- Sam mini os4.1 -- e-uae 39bb2 -- A4000D 3.0 - 2mbchip/8mbfast - Ariadne_II - ide DVD und HD -- A500 3.1 (mkick) adide 50mb -- Duron 1200mhz Ubuntu Linux [ Dieser Beitrag wurde von AGSzabo am 18.11.2009 um 16:59 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2009-11-18, 18:07 h Holger Posts: 8116 User |
Zitat:Ja, das hast Du schon mal geschrieben. Aber was zur Hölle willst Du nun eigentlich? Soll das Hauptprogramm nichts tun außer auf den Subprozess warten, das heißt soll das GUI des Hauptprogramms blockiert sein, oder nicht? Dein Hauptprogramm kann nicht gleichzeitig erst aus der filerequester-funktion zurück kehren, wenn diese beendet ist, und dafür sorgen, dass das Haupt-GUI reagiert. Das funktioniert auch mit einem Subprozess nicht. Wenn es dagegen nur darum geht, dass das "eigene GUI" des filerequesters bedient wird, das funktioniert natürlich auch ohne zusätzlichen Prozess. Einem GUI ist es nämlich vollkommen egal, ob es aus einem Unterprogramm heraus erzeugt wird oder einem eigenen Prozess. Genaugenommen ist sowieso jeder Prozess eine Art Unterprogramm. -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
| -1- 2 | [ - Post reply - ] |
| amiga-news.de Forum > Programmierung > zeiger auf globale an prozess übergeben | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |
|