Bedingungen im Initcode einer Library

amiga-news.de Forum > Programmierung > Bedingungen im Initcode einer Library

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

-1-

[ - Beitrag schreiben - ]

10.02.2012, 23:00 Uhr

AGSzabo
Posts: 1663
Nutzer

Hi,

ich habe eben merkwürdige Erfahungen beim initialieren meiner modifyle.library gemacht. Diese soll im Initcode die oxmaster.library öffnen und letztere soll für sich ein icon laden und das colorwheel gadget öffnen. Die oxmaster.lib tut noch viel mehr, öffnet andere libs. Aber unter den beschriebenen Umständen stürzt GetIconTagList() und OpenLibrary(colorwheel.gadget) ab. Woran könnte das liegen? Wenn ich die oxmaster.library direkt öffne, dann geht es. Das einzige, was diese beiden aufrufe gemeinsam zu haben scheinen ist, dass sie etwas von platte laden. Wenn ich die oxmaster.library aus irgendeiner Funktion der modifyle.library öffe, dann geht alles. Nur aus dem Initcode heraus kommt es zum Absturz.

ags
--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

[ Dieser Beitrag wurde von AGSzabo am 10.02.2012 um 23:03 Uhr geändert. ]

[ Dieser Beitrag wurde von AGSzabo am 10.02.2012 um 23:15 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.02.2012, 11:50 Uhr

jolo
Posts: 110
Nutzer

Dein InitCode muss zum einen sicherstellen, dass er nur einmal initialisiert wird. Das kannst Du sicherstellen, indem Du eine Variable (z.B. ein Bibliotheksadresse) mit dem Wert null initialisierst und in Deinem InitCode gegencheckst. Ist der Wert nicht null, verlässt Du augenblicklich den InitCode. Zum anderen musst Du eine jegliche Initialsierung, welche Festplattenzugriffe unterliegt, mit einer Schutzvorrichtung ausstatten, z.B. mit einer Signalsemaphore, ansonsten wird der OpenCode schon ausgeführt/verlassen, bevor der InitCode komplettiert werden konnte.

[ - Antworten - Zitieren - Direktlink - ]

11.02.2012, 12:57 Uhr

AGSzabo
Posts: 1663
Nutzer

@jolo:

Danke, also ausgeführt wird der Initcode nur 1x. Er ist nicht in der Open-Funktion, sondern in der Initfunktion. Oder kann es sein, dass der Initcode aus irgendwelchen Gründen nochmal aufgerufen wird? Ich bin auch schon den Initcode in Trace durch gegangen, da wird nach jedem Call, der Festplattenzugriffe aus löst, genug lang gewartet, bis er fertig ist. Oder nicht? Ich meine, vor dem Aufruf von GetIconTagList() z.B. hätte das Programm nach OpenLibrary(icon.library) im Trace Modus lang genug warten, tut es aber nicht, sondern stürzt in der Funktion ab. Es sieht - nach den Registerinhalten - ganz so aus als würde der Programcounter negativ relativ zur Addresse 0 stehen, als ob der library-base Zeiger zum Zeitpunk es Aufrufes von der Funktion 0 gewesen wäre. Aber durch die Open Funktion, welche die Iconlibrary öffnet, war ich zu dem Zeitpunkt schon durch, die hat da auch schon den richtigen Basezeiger zurückgeliefert.

ags
--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

[ Dieser Beitrag wurde von AGSzabo am 11.02.2012 um 13:02 Uhr geändert. ]

[ Dieser Beitrag wurde von AGSzabo am 11.02.2012 um 13:12 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.02.2012, 14:37 Uhr

geit
Posts: 332
[Ex-Mitglied]

@AGSzabo:

Libraries, device, settings, bilder etc nur in lib_open öffnen. lib_init ist nur zum Initialisieren globaler Resourcen wie Semaphoren gedacht.

Also in deinem Fall eine Semaphore in init mit InitSemaphore() erstellen und in lib_open diese Semaphore mit ObtainSemaphore() anfordern und auf der sicheren Seite die Libraries öffnen. Dazu brauchst du dann ja nur abzufragen, ob der jeweilige Pointer noch NULL ist. Wenn ja, dann öffnen. Am Ende schlägst du in lib_open fehl, wenn eine Library nicht geöffnet werden konnte. ReleaseSemaphore() nicht vergessen.

Schließen tust du die Libraries bei globalen libbases in lib_expunge. Bei lokalen (siehe unten) in lib_close.

Generell ist es eine gute Idee und guter Stil, wenn du die libbases nicht global definierst, sondern in der libbase selbst. Mit einem #define DosBase libbase->DosBase kannst du die Zugriffe umleiten. Das klappt aber nur, wenn du keine Linker-Libraries verwendest, die System funktionen nutzen, weil die wieder Globals verlangen. Generell sollte man auf solche Linker-Libs auch verzichten.

Dann bekommt jeder Task auch seine eigene library base. Speicher verbraucht das abgesehen von den Speicher für den Pointer nicht und du bekommst keine Probleme mit libraries, die jedem Task eine andere Base zurückgeben. z.B. bsdsocket.

Geit

[ Dieser Beitrag wurde von geit am 11.02.2012 um 14:40 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

11.02.2012, 15:21 Uhr

AGSzabo
Posts: 1663
Nutzer

@geit:

Aha. Warum funktioniert das Öffnen aus dem Initcode heraus, wenn ich es aus der oxmaster.library direkt mache? Wenn ich die oxmaster.library widerum aus einer anderen library öffne, nur dann geht es nicht.

Was soll ich mit der Semaphore locken? Nur damit meine Library nicht zweimal parallel geöffnet wird?

Ich programmiere das in assembler. "Libbase in der Libbase selbst" verstehe ich nicht.

ags

ps: jezt funktioniert es so wie du es beschrieben hast. Ich frage mich blos nach wie vor warum es erst beim indirekten Öffnen nicht funktioniert hat und wozu ich die Semafore brauche...

--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

[ Dieser Beitrag wurde von AGSzabo am 12.02.2012 um 00:00 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

12.02.2012, 16:48 Uhr

jolo
Posts: 110
Nutzer

@AGSzabo:

Zitat:
Danke, also ausgeführt wird der Initcode nur 1x. Er ist nicht in der Open-Funktion, sondern in der Initfunktion. Oder kann es sein, dass der Initcode aus irgendwelchen Gründen nochmal aufgerufen wird? Ich bin auch schon den Initcode in Trace durch gegangen, da wird nach jedem Call, der Festplattenzugriffe aus löst, genug lang gewartet, bis er fertig ist. Oder nicht?

Zum Ersten: Unter Umständen wird der InitCode nochmals aufgerufen, leider erinnere ich mich nicht mehr daran, was dazu führt. Eine Möglichkeit wäre ein Bug in OS1.x und dass ich bis dato deshalb nach wie vor eine Sicherheitsabfrage mitführe.

Zum Zweiten: Warten bis Festplattenzugriffe vervollständigt wurden verbietet sich. Das Nachrichtensystem sollte hier einspringen, jedoch setzt das dann zwingend voraus, dass LibOpen() mittels einer Semaphore solange geblockt wurde, wie LibInit() noch nicht komplettiert wurde.

Auch wenn LibInit() scheinbar von dem aufrufenden Prozess aufgelöst wird, so ist dem doch nicht so. LibInit() wird vom Prozess "RamLib" ausgeführt, LibOpen() aber vom aufrufenden Prozess (z.B der Shell). Sollte hier die "RamLib" irgendwelche DOS-Funktionen ausführen müssen, z.B. dass Nachladen externe Dateien, wird der aufrufende Prozess, der noch keinen Zugriff auf LibOpen() bekommen hat, also nur in Lauerstellung stand (von vornherein verbietet der Prozess "RamLib" das Task-Switching), wieder Rechenzeit bekommen, weil der Prozess "RamLib" ein Wait() durchführen muss (IO-Opertionen bedienen sich des Exec-Nachrichtensystems), was dazu führt, dass das Task-Switching wieder erlaubt wird, und somit wird der Code in LibOpen() ausgeführt, jedoch geht dann das Unterfangen gründlich schief, weil der "RamLib"-Prozess den LibInit()-Code noch nicht vervollständigen konnte - er hängt ja noch in der Wait()-Funktion fest.

Kurz und bündigt:

RamLib -> LibInit()
Apps -> LibOpen, LibClose, LibExpunge und alle anderen LibraryVectorOffsets

wobei beim Ausführen des Prozesses "RamLib" das Task-Switching ausgeschaltet ist, nicht jedoch beim Ausführen der ordinären Funktionen.

@geit:

Zitat:
Libraries, device, settings, bilder etc nur in lib_open öffnen. lib_init ist nur zum Initialisieren globaler Resourcen wie Semaphoren gedacht.

Könnte man so machen und würde somit vielen Fehlerquellen aus dem Weg gehen, nur leider hat Commodore Amiga es leider anders vorgemacht, weil man Bibliotheken auch von einfachen "Exec-Tasks" aus öffnen können soll. Sollte dann ein einfacher "Exec-Task" eine Bibliothek öffnen, die in LibOpen() Disk-Zugriffe ausführt, wird es wieder einmal bunt, soll heißen, wählt man LibInit() zur Initialisierung solcher Dinge, ist sichergestellt, dass ein "DOS-Process" die Aufgaben erledigt.

@AGSzabo:

Zitat:
ich programmiere das in assembler. "Libbase in der Libbase selbst" verstehe ich nicht.

Du kannst die Adressen von irgendwelchen Bibliotheken innerhalb der Basis-Struktur Deiner Bibliothek halten oder aber auf Dateiebene als globale Adresse. Im ersten Fall kannst Du sie dann nur mittels indirekter Programmierung relativ zum Prozessor-Register "A6" adressieren, im zweiten Fall aber als absolute Adresse.

code:

1)
    STRUCTURE LibraryHeader,0
    ...
    APTR    lh_GfxBase
    ...
    LABEL   SIZEOF_LibraryHeader
   
_LibOpen ; A6 -> LibraryHeader
    ...
    move.l  A6,-(sp)
    movea.l lh_GfxBase(A6),A6
    ...
    ...
    movea.l (sp)+,A6
    ...
    rts

2)
_LibOpen ; A6 -> LibraryHeader
    ...
    move.l  A6,-(sp)
    movea.l _GfxBase,A6
    ...
    ...
    movea.l (sp)+,A6
    ...
    rts

    ...

_GfxBase
    dc.l 0

[ - Antworten - Zitieren - Direktlink - ]

12.02.2012, 16:56 Uhr

AGSzabo
Posts: 1663
Nutzer

@jolo:

Ok. Soll ich nun im Open so lange warten bis Init ausgeführt wurde, oder mein Nachladen in Open machen?

Wenn ich es im Open code mache, wird die Lib im Fall eines Fehlers nicht entfernt, oder? Muss/darf ich dass dann genauso selber machen wie in Close/Expunge?

--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

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

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

[ - Antworten - Zitieren - Direktlink - ]

12.02.2012, 23:19 Uhr

jolo
Posts: 110
Nutzer

@AGSzabo:

Zitat:
Ok. Soll ich nun im Open so lange warten bis Init ausgeführt wurde, oder mein Nachladen in Open machen?

Wenn Du Dir sicher bist, dass keine Exec-Tasks Deine Bibliothek öffnen, kannst Du es getrost in LibOpen durchführen. Bitte dann aber auch die entsprechende Bemerkung in die Endanwender-Dokumentation aufnehmen.
Ansonsten, in LibInit() erst eine SignalSemaphore erschaffen (statisch oder dynamisch, ist egal) und zwar vor dem Nachladen externer Dateien, dann InitSemaphore() aufrufen und direkt im Anschluss ObtainSemaphore(). Erst dann Zugriffe auf externen Datei starten. Wenn LibInit() beendet wird, die Semaphore mit ReleaseSemaphore() als unbelegt kenntlich machen.

In LibOpen() musst Du dann nur ganz am Anfang ein ObtainSemaphore() durchführen und bei Zugriff ein ReleaseSemaphore() durchführen. Das war's dann.

Zitat:
Wenn ich es im Open code mache, wird die Lib im Fall eines Fehlers nicht entfernt, oder?

Richtig.

Zitat:
Muss/darf ich dass dann genauso selber machen wie in Close/Expunge?

Ja, sollte funktionieren, da die Funktion OpenLibrary() sowieso im Forbid-Zustand ausgeführt wird.

[ - Antworten - Zitieren - Direktlink - ]

13.02.2012, 14:38 Uhr

AGSzabo
Posts: 1663
Nutzer

@jolo:

Ok, ich habe das jetzt mal umgesetzt. Es funktioniert aber nicht, sondern bleibt hängen. Man kann dann zwar noch auf der WB herumspielen, aber keine Programme mehr starten. Liegt vieleicht daran, dass ich im Initcode auf Signale von einem dort gestarten Prozess warte?

Außerdem, wenn der Open code dran kommen kann, während der Init-Code noch ausgeführt wird, kann es doch theoretisch dazu kommen, dass Init failt und auch dann wieder die Semaphore frei gibt, aber Open noch in der Semaphore hing und diese jetzt bekommt, und die Lib dem aufrufenden Programm öffnet, aber da ja Init gefailt ist, die Lib dem aufrufenden Programm unter den Füßen weggezogen wird. Oder?
--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

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

[ - Antworten - Zitieren - Direktlink - ]

13.02.2012, 16:36 Uhr

geit
Posts: 332
[Ex-Mitglied]

Das ist genau der Grund, warum man in Init nichts machen soll, das andere Tasks involviert und genau das passiert bei OpenLibrary(), Open() oder CreateTask()

Du darfst nicht warten, weil zu dem Zeitpunkt niemand da ist, der dir Signale senden wird. Außerdem sollte LibInit() so kurz wie möglich sein, weil eben alle anderen Tasks in diesem Moment still stehen. Libraries sind eine sehr fragile Geschichte, wenn sie falsch implementiert werden, dann kann man das System mit einem avail flush abschießen oder bekommt Systemweite lockups.

LibInit läuft auch nicht im Task des Aufrufers, sondern im Task der RamLib. Wenn du dort Signale allokierst, dann haben die keine Funktion. Außerdem hat der RamLib Task einen sehr kleinen Stack.

Der Hauptgrund, warum man keine Libraries öffnen soll, ist die Tatsache, das LibInit() im Forbid() state läuft. Es findet kein Taskswitching mehr statt. Der Grund ist einfach. Was wäre wenn zwei Tasks/Programme ziemlich gleichzeitig die selbe Library öffnen. In dem Fall kommen beide Zeitnahm in libinit() und es würde zweimal aufgerufen. Das wird durch den Forbid() verhindert. Das Aufrufen von DOS Operationen kann diesen Forbid aber brechen. Du bist mit deinem Init noch nicht fertig, aber ein zweiter Task rauscht in die gleiche libinit() Routine rein. Öffnet die selbe Library noch einmal und speichert den Pointer in der selben Speicherstelle. Chaos pur.

Abstrakt sollte das so aussehen:

LibInit:
InitSemaphore()
ObtainSemaphore() /* wegen der Sicherheit */
... Speicherallokieren, defaults setzen
ReleaseSemaphore()
Return

LibOpen:
ObtainSemaphore()
if( DOSBase == 0 ) {
DOSBase = Open( "dos.library",0)
}
if( DOSBase == 0 ) {
ReleaseSempaphore()
Return( NULL );
}
ReleaseSemaphore()
return( libbase )

Wenn du also einen Task in LibInit startest, dann kannst du ewig warten, weil der nie aufgeführt wird und der Taskwechsel abgeschaltet ist.

Das machst du in LibOpen(). Im Prinzip wie bei der dos.library oben.

Wenn der TaskPointer NULL ist, mußt du noch einen Subtask starten, wenn nicht, dann nicht. Die Semaphore schützt dich davor, das durch paralleles öffnen mehrerer Tasks auch mehrere Tasks gestartet werden, weil nur ein Task zur selben Zeit hinter den ObtainSempahore kommt.

Der Programmkode wird durch die sempahoren zwar etwas komplexer, aber da man ja nicht 1000 mal pro Sekunde die Library öffnet, fällt das nicht weiter ins Gewicht und ist absolut sicher.

Der LibInit() Code wird auch nur einmal aufgerufen. Danach bekommst du nur noch LibOpen() und LibClose(). Wenn du den OpenCNT in der Libbase richtig zählst, dann wir niemandem etwas unter dem Hintern weggezogen, weil LibExpunge() die library nur entsorgt, wenn der Counter auf 0 ist, also genauso viele LibClose() wie LibOpen() eingetroffen sind.

Geit

[ Dieser Beitrag wurde von geit am 13.02.2012 um 16:55 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

13.02.2012, 16:49 Uhr

AGSzabo
Posts: 1663
Nutzer

@geit:

Aha, klingt einleuchtend.

--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

[ - Antworten - Zitieren - Direktlink - ]

13.02.2012, 18:46 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von geit:
Das ist genau der Grund, warum man in Init nichts machen soll, das andere Tasks involviert und genau das passiert bei OpenLibrary(), Open() oder CreateTask()

Mindestens OpenLibrary wirst Du in jedem Beispielcode finden, inkl. RKRM, da habe ich gerade extra nachgesehen.

Zitat:
Du darfst nicht warten, weil zu dem Zeitpunkt niemand da ist, der dir Signale senden wird. Außerdem sollte LibInit() so kurz wie möglich sein, weil eben alle anderen Tasks in diesem Moment still stehen.

Da für die Open-Funktion exakt dasselbe gilt, ist das kein sinnvolles Argument.

Zitat:
LibInit läuft auch nicht im Task des Aufrufers, sondern im Task der RamLib. Wenn du dort Signale allokierst, dann haben die keine Funktion. Außerdem hat der RamLib Task einen sehr kleinen Stack.

Wie hier bereits erwähnt wurde, ist der Task der RamLib ein Prozess, was man vom OpenLibrary Aufrufer nicht mit Sicherheit sagen kann. Dessen Stackgröße kennen wir auch nicht.

Zitat:
Der Hauptgrund, warum man keine Libraries öffnen soll, ist die Tatsache, das LibInit() im Forbid() state läuft. Es findet kein Taskswitching mehr statt.

Wie bei lib/Open auch.

Zitat:
Der Grund ist einfach. Was wäre wenn zwei Tasks/Programme ziemlich gleichzeitig die selbe Library öffnen. In dem Fall kommen beide Zeitnahm in libinit() und es würde zweimal aufgerufen. Das wird durch den Forbid() verhindert. Das Aufrufen von DOS Operationen kann diesen Forbid aber brechen.

Das überzeugt mich nicht. Noch bevor die Init-Routine aufgerufen wird, muss die Library mit eben jenen DOS-Operationen von der Platte geladen werden. Somit ist in jedem Fall ein externer Schutzmechanismus seitens der RamLib vonnöten, der auch ein nicht abgeschaltetes Multitasking aushält.

Zitat:
Du bist mit deinem Init noch nicht fertig, aber ein zweiter Task rauscht in die gleiche libinit() Routine rein. Öffnet die selbe Library noch einmal und speichert den Pointer in der selben Speicherstelle. Chaos pur.

Siehe oben: wenn die RamLib keinen zusätzlichen Schutzmechanismus besitzen würde, könnte das schon passieren bevor die Init-Funktion aufgerufen wird. Sogar mit einer parallel geladenen zweiten Fassung der Library. Das wäre erst mal ein Chaos.

Zitat:
Abstrakt sollte das so aussehen:

LibInit:
InitSemaphore()
ObtainSemaphore() /* wegen der Sicherheit */
... Speicherallokieren, defaults setzen
ReleaseSemaphore()
Return

LibOpen:
ObtainSemaphore()

...

So, und wie sollte dieser Code das hypothetische zweite Aufrufen der Init-Funktion verhindern? Die Semaphore würde ja beim zweiten Aufruf komplett übergebügelt werden, bevor überhaupt der Versuch gemacht wird, sie zu locken. Das wäre nicht gesund. Zum Glück gibt es ja kein solches zweites Aufrufen.

Zitat:
Wenn du also einen Task in LibInit startest, dann kannst du ewig warten, weil der nie aufgeführt wird und der Taskwechsel abgeschaltet ist.

Hat er irgendwo geschrieben, dass er das vorhat?

Zitat:
Das machst du in LibOpen().

Wo der Taskwechsel ebenfalls abgeschaltet ist...

Zitat:
Der Programmkode wird durch die sempahoren zwar etwas komplexer, aber da man ja nicht 1000 mal pro Sekunde die Library öffnet, fällt das nicht weiter ins Gewicht und ist absolut sicher.

Was ich arg bezweifeln möchte.

Was macht denn die Exec.Library, wenn ein Task eine momentan nicht verfügbare Semaphore locken will?

Doch wohl exakt dasselbe, wie beim Aufruf einer Dos-Funktion: der Task wartet bis die Semaphore verfügbar wird. Wird also schlafen gelegt und das Multitasking läuft wieder an.

Wo soll da das Mehr an Sicherheit herkommen?

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

13.02.2012, 18:55 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

Dochdoch, ich will "am Anfang" der library einen Prozess starten. Das geht auch, solange ich es im Open-code der library mache. Mein Glück, oder so vorgesehen?
--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

[ - Antworten - Zitieren - Direktlink - ]

14.02.2012, 09:55 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
Dochdoch, ich will "am Anfang" der library einen Prozess starten.

Hast Du hier aber nicht geschrieben, oder habe ich was übersehen?

Zitat:
Das geht auch, solange ich es im Open-code der library mache. Mein Glück, oder so vorgesehen?

Starten kannst Du ihn überall. Nur auf diesen neuen Prozess Warten hat die hier erwähnten Nebeneffekte.

Ich vermute mal, dass Du Deinem neuen Prozess die Library-Adresse mitgibst. Das dürfte der Grund sein, warum es nicht funktioniert, wenn Du ihn aus der LibInit-Funktion startest. Dann kann es nämlich tatsächlich passieren, dass Dein neuer Prozess auf die Library zugreift, bevor die Initialisierung abgeschlossen ist.

Das ist aber auch das einzige Szenario. Kein anderer Task/Prozess kennt die Basisadresse Deiner Library, bevor nicht die Initialisierung abgeschlossen ist.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.02.2012, 10:40 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

> Hast Du hier aber nicht geschrieben, oder habe ich was übersehen?

http://www.amiga-news.de/forum/thread.php?id=34350&BoardID=7#355660
--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

[ - Antworten - Zitieren - Direktlink - ]

14.02.2012, 10:50 Uhr

Holger
Posts: 8116
Nutzer

@AGSzabo:
Ach so. Und was genau macht Dein neu gestarteter Prozess nun?
Also, bevor er das Signal schickt, auf das Du in der Library warten willst.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

14.02.2012, 11:13 Uhr

AGSzabo
Posts: 1663
Nutzer

@Holger:

Der neue Prozess kümmert sich um das GUI. Er öffnet die oxmaster.library und erstellt eine ox-application, die für alle kommenden Requester und Fenster da ist. Es wird gewartet, bis das vollbracht ist oder failt. Erst dann geht es weiter.
--
Author of Open eXternal User Interfaces, eXternal Format Rippers and the Book "Torakosmos". Developing with E-UAE on an Ubuntu dualcore system.

[ - Antworten - Zitieren - Direktlink - ]

14.02.2012, 19:40 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von AGSzabo:
Der neue Prozess kümmert sich um das GUI. Er öffnet die oxmaster.library und erstellt eine ox-application, die für alle kommenden Requester und Fenster da ist. Es wird gewartet, bis das vollbracht ist oder failt. Erst dann geht es weiter.

Ne Menge Holz. Und damit ist es auch logisch, dass es zu einem Dead-Lock kommen kann: befindet sich unter den Libraries (bzw. Library-ähnlichen Ressourcen wie externen Gadgets), die direkt oder indirekt von Deinem neuen Prozess geöffnet werden, eine, die noch nicht im RAM liegt, wird versucht, diese über den Prozess der ramlib zu laden. Dieser befindet sich aber immer noch in Deiner LibInit-Routine, die auf das Signal wartet. Somit kann es nie zu einer Antwort kommen.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Bedingungen im Initcode einer Library

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