Prozess aus library initcode starten?

amiga-news.de Forum > Programmierung > Prozess aus library initcode starten?

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

27.11.2017, 01:33 Uhr

AGSzabo
Posts: 1663
Nutzer

Hi, ich möchte meiner GUI library einen im Hintegrund laufenden Server für manche GUI elemente einführen, auf der Basis eines Prozess oder Task. Gibt es da irgndwelche Einschränkungen was dieser Process darf? Denn die ramlib führt ja die lib initialisierung aus! Und da bekam mein GUI schonmal probleme als ich versuchte von dort aus etwas ähnliches zu tun.

In den Buttons des GUI hängen meistens Hooks, die sollte aber wiederum die user app ausführen, obwohl der GUI Server darauf kommt. Ich vermute das beste ist ich sende dann eine passage an einen port der user app. das könnte synchron (mit wait auf replymgs? wie geht das dass der server wartet bis die message replied wird?) und asynchron geschehen falls das letztere keine Gefahren birgt. Ich könnte auch stattdessen für asynchrone AUsführung einen kleinen Task oder Process starten. Welche Hrangehenweise ist die empfehlsamste?

Andreas
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ Dieser Beitrag wurde von AGSzabo am 27.11.2017 um 01:37 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

27.11.2017, 17:16 Uhr

thomas
Posts: 7716
Nutzer

[quote]
Original von AGSzabo:
Hi, ich möchte meiner GUI library einen im Hintegrund laufenden Server für manche GUI elemente einführen, auf der Basis eines Prozess oder Task. Gibt es da irgndwelche Einschränkungen was dieser Process darf?[quote]

Kommt drauf an, ob du eine Task oder einen Prozess machst. Eine Task darf keine DOS-Calls machen.

Zitat:
Denn die ramlib führt ja die lib initialisierung aus! Und da bekam mein GUI schonmal probleme als ich versuchte von dort aus etwas ähnliches zu tun.

CreateNewProc in der Init-Proc müsste gehen. Die ramlib ist etwas knapp mit Stack ausgestattet, d.h. deine Init-Proc sollte recht sparsam sein und deinem neuen Prozess solltest du eine großzügige StackSize mitgeben und nicht die des Mutterprozesses erben lassen.

Zitat:
In den Buttons des GUI hängen meistens Hooks, die sollte aber wiederum die user app ausführen, obwohl der GUI Server darauf kommt. Ich vermute das beste ist ich sende dann eine passage an einen port der user app. das könnte synchron (mit wait auf replymgs? wie geht das dass der server wartet bis die message replied wird?) und asynchron geschehen falls das letztere keine Gefahren birgt. Ich könnte auch stattdessen für asynchrone AUsführung einen kleinen Task oder Process starten. Welche Hrangehenweise ist die empfehlsamste?

Das gute an PutMsg/GetMsg ist, dass du das Protokoll selbst bestimmen kannst.

Damit der Server auf Antwort warten kann, muss er einen eigenen MsgPort anlegen, der in msg->mn_ReplyPort eingetragen wird.

Also etwa so:

msg->mn_ReplyPort = serverport;
PutMsg (userport, msg);
WaitPort (serverport);

und im User-Programm dann so:

msg = GetMsg (userport);
/* msg verarbeiten */
ReplyMsg (msg);

Du merkst aber schon, dass du hier gerade das IDCMP nachprogrammierst?

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

01.12.2017, 14:54 Uhr

AGSzabo
Posts: 1663
Nutzer

@thomas:

Ja, das wäre dann so eine Art ähnlich wie IDCMP. Der Grund liegt darin dass mein gui zwar child processe starten kann um längeraduernde Dinge zu tun, aber das Button zB bleibt im gedrückten zustand noch gezeichnet, auch wen der Klick schon verarbeitet wird, bis der fertig ist. Reagieren tu ich auf Maus-Up aber zum zeichnen reicht das nicht, weil das zeihcnen nach dem ausführen des hooks, nicht nach der rückehr der bearbeiten des objektebaum (und gezeichet wird immer erst wenn ein event ganz bearbeitet wurde, also wenn ein hook am even hängt dann wird auf den auch gewartet)s
--
Webmaster of Kestra Bitworld. Author of Open eXternal User Interfaces, eXternal Format Rippers and "Torakosmos".

[ Dieser Beitrag wurde von AGSzabo am 01.12.2017 um 14:54 Uhr geändert. ]

[ Dieser Beitrag wurde von AGSzabo am 01.12.2017 um 17:54 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

03.12.2017, 18:14 Uhr

olsen
Posts: 4
Nutzer

Zitat:
Original von AGSzabo:
Hi, ich möchte meiner GUI library einen im Hintegrund laufenden Server für manche GUI elemente einführen, auf der Basis eines Prozess oder Task. Gibt es da irgndwelche Einschränkungen was dieser Process darf?

Ich rate davon ab, in der init-Funktion von library/device mehr als nur die absolut notwendigstens Dinge zu erledigen. Diese Funktion wird von ramlib aufgerufen, und wenn man sich dort einmal "verklemmt", weil man z.B. indirekt libraries, devices, usw. öffnet und die dos.library sich mit requester meldet, kann man andere Prozesse/Tasks am Öffnen von libraries, devices hindern. Das geht mitunter nicht gut aus, und die Grundursache vom Fehlverhalten lässt sich schwer zurückverfolgen.

Stattdessen würde ich empfehlen, das Erzeugen von Prozessen, usw. in die open-Funktion von library/device zu verlegen, wenn das denn möglich ist. Das muss dann über SignalSemaphore abgesichert werden, was die Sache ein Stück komplexer macht, da die open-Funktion unter Forbid() aufgerufen wird. Aber wird dort etwas durch indirekten Aufruf von dos.library-Funktionen verzögert, dann sind nur die Prozesse/Tasks betroffen, die bei der SignalSemaphore warten, und nicht gleich alle Nutzer von ramlib.

In der bsdsocket.library von Roadshow werden die Prozesse ausschließlich innerhalb der open-Funktion erzeugt, und auch nur wenn die bsdsocket.library zum ersten Mal geöffnet wird. Das Gegenstück dazu gibt es dann in der close-Funktion, wenn die bsdsocket.library zum letzten Mal geschlossen wird.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Prozess aus library initcode starten?

[ - Suche - Neue Beiträge - Registrieren - Login - ]