Sockets - Probleme mit Subprozessen

amiga-news.de Forum > Programmierung > Sockets - Probleme mit Subprozessen

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

-1-

[ - Beitrag schreiben - ]

20.04.2003, 22:43 Uhr

Inferno
Posts: 157
Nutzer

Hallo,

ich habe da noch eine Frage zu Sockets. Diesmal im Zusammenhang mit Subprozessen.

Mein Problem:
Solange ich alles als Programm mit nur einem Prozess ausführe, klappt es einwandfrei.

Rufe ich aber socket-library-funktionen aus einem Subprozess heraus auf, dann funktioniert das nur, wenn ich zuvor in jedem Sub-Prozess die Library erneut lade (OpenLibrary). Dadurch überschreibe ich aber den Pointer der vorher geöffneten Library (denn der Linker verlangt ja, daß die Lib in einer globalen Variablen mit namen "SocketBase" geladen wird), so daß ich diese nicht mehr alle freigeben kann.

Noch dazu kann es dazu kommen, daß sich zwei Prozesse gegenseitig behindern, wenn sie nacheinander die Lib neu reinladen. Einer von beiden geht dann in eine Endlosschleife ....

Hat jemand von Euch ähnliche Probleme gehabt / gelöst???

Ich habe mir überlegt, alle Socket-Zugriffe über einen eigenen Prozess durchzuführen, der mit allen anderen dann per Messages die Infos austauscht. Dadurch müßte ich die Lib nur einmal laden und kann sie auch korrekt wieder freigeben.

Auf jeden Fall bin ich für jeden Input zu haben

Ciao,

Inf.

[ - Antworten - Zitieren - Direktlink - ]

21.04.2003, 08:50 Uhr

thomas
Posts: 7718
Nutzer

Zitat:
Rufe ich aber socket-library-funktionen aus einem Subprozess heraus auf, dann funktioniert das nur, wenn ich zuvor in jedem Sub-Prozess die Library erneut lade (OpenLibrary). Dadurch überschreibe ich aber den Pointer der vorher geöffneten Library (denn der Linker verlangt ja, daß die Lib in einer globalen Variablen mit namen "SocketBase" geladen wird), so daß ich diese nicht mehr alle freigeben kann.

Das stimmt so nicht.

Erstens OpenLibrary lädt die Lib nicht jedesmal neu, sondern benutzt die eine Kopie, die schon geladen wurde. Zweitens du bekommst bei jedem OpenLibrary den selben Pointer auf die selbe Library-Base. Du kannst also beruhigt aus jedem Prozess die Lib neu öffnen und anschließend schließen.

Ok, das gilt für jede mir bekannte Library, normalerweise kann man den Lib-Pointer auch von fremden Prozessen benutzen. Warum das bei der Socket-Lib nicht gehen soll, weiß ich nicht.

Gruß Thomas

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

[ - Antworten - Zitieren - Direktlink - ]

21.04.2003, 09:13 Uhr

Inferno
Posts: 157
Nutzer

Hallo Thomas,

ja, das hatte ich gehofft. Ist halt wirklich seltsam, daß man den selben Pointer mit dem SELBEN Wert nochmal laden muß, damit es funktioniert ... Allerdings favorisiere ich die Lösung mit einem extra-Prozess der das Socket-handling macht, weil ich Bedenken habe, was mit evtl. noch offenen Sockets aus anderen Prozessen passieren würde, wenn ich in einem Prozess die Lib schliesse ...

Würde mich mal interessieren, wie das mit OS 4 ausschaut

Ciao,

Inf.

[ - Antworten - Zitieren - Direktlink - ]

21.04.2003, 09:18 Uhr

Inferno
Posts: 157
Nutzer

Hallo nochmal,

habe das eben mal getestet wegen der gleichen Pointer, ABER:

Erstaunlicherweise ist der Pointer, den ich beim Aufruf von OpenLibrary("bsdsocket.library", 0L) in einem Subprozess erhalte UNTERSCHIEDLICH zu dem, den ich in einem Anderen Prozess bekomme...

DAS kann ich mir nun leider gar nicht erklären

Gruß,

Inf.

[ - Antworten - Zitieren - Direktlink - ]

21.04.2003, 10:17 Uhr

thomash
Posts: 172
Nutzer

Hi.

Zitat:
Original von Inferno:
Hallo nochmal,

habe das eben mal getestet wegen der gleichen Pointer, ABER:

Erstaunlicherweise ist der Pointer, den ich beim Aufruf von OpenLibrary("bsdsocket.library", 0L) in einem Subprozess erhalte UNTERSCHIEDLICH zu dem, den ich in einem Anderen Prozess bekomme...

DAS kann ich mir nun leider gar nicht erklären

Gruß,

Inf.

Wahrscheinlich führt die bsdsocket.library Buch über geöffnete Filehandles (Sockets) pro Prozess. Das heißt, daß jeder Prozess eine eigene Verwaltungsstruktur bekommt. Nur ist mir rätselhaft, warum sich dann die Basisadresse ändert. Dann muß die Library ja jedesmal die Sprungtabelle mit kopieren und anpassen.

Das kopieren des Basiszeigers in andere Prozesse ist für manche Libraries ausdrücklich verboten (mathxxxx.library). Vielleicht fällt die bsdsocket.library auch darunter. Da hilft nur Anleitung lesen.

Das mit dem blockieren einer Library, wenn mehr als ein Prozess sie öffnet, hatte ich auch mal. Die einzige Lösung war damals, sie per LoadResource (Shell-Befehl) vorzuladen. Ich habe dann aber auch nicht weiter in der Richtung nach anderen Lösungen gesucht.

Ciao,
Hoin.

[ - Antworten - Zitieren - Direktlink - ]

28.04.2003, 10:09 Uhr

gni
Posts: 1106
Nutzer

Zitat:
Das stimmt so nicht.

Das kann man so stehen lassen ;-)

Zitat:
Erstens OpenLibrary lädt die Lib nicht jedesmal neu, sondern benutzt die eine Kopie, die schon geladen wurde.

Anders gehts ja auch nicht. Um genau zu sein, der Code wird wiederbenutzt.

Zitat:
Zweitens du bekommst bei jedem OpenLibrary den selben Pointer auf die selbe Library-Base. Du kannst also beruhigt aus jedem Prozess die Lib neu öffnen und anschließend schließen.

Und das stimmt _nicht_! Es ist nicht zwingend das OpenLibrary() immer den selben Wert für eine Bibliothek zurückliefert. MultiBase Libraries sind legal und werden auch verwendet. Das beste Beispiel ist die bsdsocket Library. Es ist ausdrücklich dokumentiert, das diese Bibliothek
von jedem Prozess selber zu öffnen ist.

Zitat:
Ok, das gilt für jede mir bekannte Library, normalerweise kann man den Lib-Pointer auch von fremden Prozessen benutzen. Warum das bei der Socket-Lib nicht gehen soll, weiß ich nicht.

Oft, aber nicht immer.

[ Dieser Beitrag wurde von gni am 28.04.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

28.04.2003, 10:14 Uhr

gni
Posts: 1106
Nutzer

Zitat:
thomash:
Wahrscheinlich führt die bsdsocket.library Buch über geöffnete Filehandles (Sockets) pro Prozess. Das heißt, daß jeder Prozess eine eigene Verwaltungsstruktur bekommt. Nur ist mir rätselhaft, warum sich dann die Basisadresse ändert. Dann muß die Library ja jedesmal die Sprungtabelle mit kopieren und anpassen.

Warum die bsdsocket.library das fordert, ist nicht wichtig. Man muß es aber beachten ;-) Wenns Dich interessiert, es gibt die Quellen für AmiTCP3Beta2.
Das Erstellen einer neuen Basis ist nicht weiter schwierig, das wird per MakeLibrary() gemacht.

Zitat:
Das kopieren des Basiszeigers in andere Prozesse ist für manche Libraries ausdrücklich verboten (mathxxxx.library). Vielleicht fällt die bsdsocket.library auch darunter. Da hilft nur Anleitung lesen.

Eine gute Empfehlung ;-)

[ - Antworten - Zitieren - Direktlink - ]

29.04.2003, 10:10 Uhr

Inferno
Posts: 157
Nutzer

Hallo Leute,

habe jetzt bestimmt einige Stunden damit verbracht, im Internet und in Dokus zu stöbern. Dabei habe ich folgendes zu Tage gebracht:

1) Es gibt wohl ein flag, mit dem man die Library so umstellen kann, daß mehrere Prozesse sie über die gleiche "Library *SocketBase" benutzen können "STBC_blablabla". Dummerweise stand nicht dabei, WIE man das machen soll.

2) Alternativ muß die Library für jeden Prozess neu geöffnet werden, da sie eine Tabelle von Handles pro Prozess führt.

Da im zweiten Fall die Verwendung von dem gleichen Socket über verschiedene Prozesse recht kompliziert ist, würde ich gerne zum Trick 1) greifen.

Kennt sich hier jemand genauer damit aus und kann mir evtl. einen Beispiel-Code posten?

Gruß,

Inf.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2003, 11:16 Uhr

gni
Posts: 1106
Nutzer

Zitat:
Inferno:
habe jetzt bestimmt einige Stunden damit verbracht, im Internet und in Dokus zu stöbern. Dabei habe ich folgendes zu Tage gebracht:

In welchen?

Zitat:
1) Es gibt wohl ein flag, mit dem man die Library so umstellen kann, daß mehrere Prozesse sie über die gleiche "Library *SocketBase" benutzen können "STBC_blablabla".

Wo hast Du das gelesen? Im AmiTCP-4.3 SDK ist davon nichts zu finden.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2003, 12:34 Uhr

Inferno
Posts: 157
Nutzer

Aus 'nem bsdsocket.doc das mir ein Bekannter zugeschickt hatte:

--- snip ---
NAME
SocketBaseTagList - get/set global library attributes

SYNOPSIS
result = SocketBaseTagList(tags)
D0 A0

long SocketBaseTagList(struct TagItem *tags);

long SocketBaseTags(Tag first_tag, ...);

FUNCTION
This function is for querying and changing attributes of the
stack's state information.

--- /snip ---

und dann ein bisserl weiter (aber immer noch SocketBaseTagList):

--- snip ---

SBTC_CAN_SHARE_LIBRARY_BASES
This tag is an extension to the AmiTCP V4 API and cannot
be expected to be supported by older "bsdsocket.library"
versions.

Normally, every client to call "bsdsocket.library"
routines will have to reopen the library and obtain its
own instance of the per-library base variables. The
SBTC_CAN_SHARE_LIBRARY_BASES tag can be used to allow
several Tasks/Processes to share a single library
base. Note that error reporting will become rather
difficult if you do this, as there is only one instance
of the library state variables per base. Also, the
signal delivery mechanisms behind SBTC_SIGIOMASK,
SBTC_SIGEVENTMASK and SBTC_SIGURGMASK will only work for
the Process that configured them.

This option only has local impact in that it affects only
the single library base for which it was configured.

--- /snip ---

Kannst Du damit was anfangen? (Insbes. WIE man das verwendet?)

Ciao,

Inf.

[ - Antworten - Zitieren - Direktlink - ]

29.04.2003, 13:31 Uhr

gni
Posts: 1106
Nutzer

Zitat:
Inferno:
Aus 'nem bsdsocket.doc das mir ein Bekannter zugeschickt hatte:

Konkret vom welchem Stack? Das ist _wichtig_

Zitat:
SBTC_CAN_SHARE_LIBRARY_BASES
This tag is an extension to the AmiTCP V4 API and cannot
be expected to be supported by older "bsdsocket.library"
versions.

Da es eine Erweietung zum V4 API ist, kannst Du die Verwendung des Flags vergessen.

Zitat:
This option only has local impact in that it affects only
the single library base for which it was configured.

Das soll vermutlich heissen, das man nach Aktivierung dieser Erweiterung die Basis in meheren Prozessen nutzen kann, dh. OpenLibrary() kann entfallen.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Sockets - Probleme mit Subprozessen

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