Pointer auf Klasse in statische Memberfunktion via Shared Memory
-
Hi,
steh momentan leider ein wenig auf der Leitung und habe folgendes Problem.
In einem Thread (via Klasse realisiert) gibts eine Datenbankabfrage, die die Ergebnisse über eine Callback-Funktion zurückgibt.
Die Callback-Funktion hab ich als statische Memberfunktion der Klasse definiert, es könnte aber auch jede andere eigenständige Funktion sein.
Vor der Datenbankabfrage wird im Thread noch eine TCP/IP Server-Verbindung erstellt, um die Daten zu übermitteln.Meine Idee Dazu: Ich übergebe in die Callback-Funktion einen Pointer auf die Threadklasse und greif von dort wieder auf eine TCP/IP Send-Funktion zurück. Problem dabei: Ich hab keine Zugriff auf die Definition der Callback-Funktion. Daher möchte ich das über einen Shared Memory-Bereich erledigen. Die Idee dazu:
- Die Thread-Klasse erstellt ein SharedMemory und schreibt die Adresse der Klasse (this) drauf
- Die Callback-Funktion liest den Pointer aus und hat somit Zugriff auf die Member der Thread-Klasse
- Die Daten aus der Datenbank-Abfrage werden als Parameter in die TCP/IP Send Funktion übergeben und verschickt.Kann das funktionieren?
Wenn ja, wie geht das mit den Pointern? Vorallem das Draufschreiben der Klassenadresse in den Shared-Memory Bereich kapier ich im Moment nicht...Mein Code dazu:
int shmid;
void *shmdata; // Pointer zum Shared-Memory Bereich
key_t key=0x67656F6D;FooThread *pFooThread=NULL; // Pointer auf die Thread-Klasse
pFooThread=this;shmid = shmget (key, sizeof(pFooThread),
IPC_CREAT | SHM_R | SHM_W);// Bind shared memory segment
shmdata = shmat (shmid, NULL, 0);memcpy(shmdata,pFooThread,sizeof(pFooThread)); // ???????
In der Callback würde ich shmdata dereferenzieren und die Memberfunktion aufrufen...
Bitte um einen Ratschlag...
Gruss, Günther
-
Das klingt aehm irgendwie sehr abenteuerlich
gibts eine Datenbankabfrage, die die Ergebnisse über eine Callback-Funktion zurückgibt.
das ist gar ned so unueblich ....
Allerdings haben die meisten callbacks (da sie ja eigentlich globale funtionen sind) meist nen context object in irgend ner form. weil sonst sind die kaum benutzbar ....das heisst du uebergibst beim Aufruf deiner Abfrage den context und die callbackadresse, und bei der ausfuehrung dann wird dein callback aufgerufen und der context wieder mit als parameter uebergeben. das nutzt man dann meist um den initiator callbacks zu identifizieren (z.b. wieder in die Instanz der klasse zu kommen) und hat dann zugriff auf noch benoetigte Daten ...
post mal die die protytpen der DB schnittstelle fuer die Abfrage und fuer den Callback !
Ciao ...
-
Du benötigst IPC (Pipes, MailSlots, TCP/IP, UDP, MMF, etc.).
Über Shared Memory Daten auszutauschen ist ok. Nicht jedoch Adressen von Objekten (austauschen geht natürlich, nur ist diese Adress im anderen Prozess ungültig (bzw. hat keine Bedeutung)).Simon
-
Er schreibt ned, dass er die "Adressen" ueber TCP/IP austauschen will ...
sondern es klingt eher, als ob er den shm mit den adressen zum austausch der daten zwischen 2 threads verwenden will.
Entweder meint er mit shared memory was anderes (obwohl shmat schon nach shm aussieht), oder es waer ned notwendig, das sich threads ja im selben prozess befinden und eh einfach ueber den datenbereich austauschen koennen.
Oder ich hab was ned richtig verstanden ... ^^Ciao ...
-
Danke für die Tipps.
also: Die Callback-Funktion ist als statische Memberfunktion meiner Thread-Klasse definiert. Daher hat sie keinen impliziten Pointer auf das Objekt (bzw. die Thread Klasse). Ich hab jetzt nach einer Möglichkeit gesucht, aus der Callback-funktion auf die anderen, nicht statischen Memberfunktionen der Thread-Klasse zuzugreifen.
Über Shared Memory einen Pointer ("this") der Thread-Klasse in die statische Memberfunktion zu übergeben und dort über casting auf die Member-Funktionen zuzugreifen müsste meiner Meinung nach schon funktionieren.
@RHBaum: Du hattest allerdings recht: Der Aufruf der Callback-Funktion hatte doch noch einen weiteren Pointer als Parameter, in dem ich die Instanz der Klasse gleich mitgeben kann. Somit erspare ich mir auch den Umweg über Shared Memory...
-
Und bei Threads brauchst du gar kein shared memory !
threads nutzen den selben datenbereich, das heisst, das globale variablen auf die selben "Daten" referenzieren, ueber alle threads hinweg.
Das ist grad der vorteil von threads, das sie eben keinen eigenen stack anfordern und keine kopie der prozessumgebung beim erzeugen gemacht werden muss.shared memory gehoert zur IPC, nimmt man bei mehreren prozessen (fork, oder gar fremde prozesse) um daten auszutauschen.
Ciao ...