[gelöst] Shared Memory mit QT

[bw1faeh0]

Hallo Leute,

im Anschluss an das Thema von gestern (schnelle Ausgabe von Text auf dem Bildschirm) habe ich mir über nacht noch ein anderes Konzept überlegt, Text auf dem Bildschirm auszugeben.
Ich schreibe eine Konsolen-Anwendung, die den Ausgabetext in die Konsole plottet und mittels Shared Memory mit der QT-Anwendung kommuniziert.

Nun die Preisfrage:
Gibt es dafür von QT bereits eine Unterstützung für shared Memory, oder muss ich dass in C implementieren?

Grüße

Christian

[Christian81]

Nein, erst ab 4.4: http://doc.trolltech.com/main-snapshot/ ... emory.html

Aber eine Komminikation über Pipes würde doch auch gehen...

[bw1faeh0]

mhh... pipes... da muss ich wohl mal googlen

[bw1faeh0]

könnte ich es nicht in Standard-C implementieren??

[RHBaum]

DU kannst alles implementieren in C, wenn du nur willst

IPC ist immer teil des BS, nur wenn glueck hasst, gibt es eine Abstraktionsschicht drueber, die es fuer mehrere BS gibt (Sockets z.b.)

In deinem fall, bau ne Lib (.so /dll) die dir die kommunikation ueber Shared memory implementiert, und zieh die halt in deiner konsolenanwendung und in deiner QT App an. sollte kein problem sein ....

CIao ...

[FaS]

Du kannst deiner Qt-Anwendung mit "CONFIG += console" auch so eine Konsole hinzufügen, dann brauchst du nicht 2 Programme dafür und ersparst dir die Kommunikation.

MfG,
FaS

[bw1faeh0]

FaS:

Dein Vorschlag klingt interessant, jedoch habe ich das Problem, dass ich bis zu acht parallele Ausgaben auf 8 Konsolen managen muss. Kann ich dieses Problem auch damit lösen, dass ich mehrer Instanzen einer Konsole öffne??

[FaS]

Ich denke mehr als 1 Konsole pro Programm ist nicht so ohne weiteres möglich.
Aber du könntest ein Konsolenprogramm (mit oder ohne Qt) erstellen und dieses mit QProcess vom Hauptprogramm aus so oft starten wie benötigt. Das tolle ist, du kannst dann mit write() (geht als std::in ein), read() (std::out lesen) usw. mit ihm Kommunizieren, siehe Doku. Muss man nur gucken in wiefern der seine Ausgaben dann (auch) in die Konsole schreibt statt sie dem Hauptprogramm zu übermitteln, vielleicht reicht auch QProcess::closeReadChannel( QProcess::StandardOutput ).
Aber ob das alles so gut funktioniert kann ich nicht sagen.
Ggf. kannst du ja auch UDP zur Kommunikation benutzen, aber ob das so schick ist.. (aber funktioniert das Fenstermanagement unter Linux nicht auch über TCP/IP-Kommunikation? Und UDP ist sogar schneller)

Außerdem: ist es nicht etwas unübersichtlich, wenn da lauter Konsolen auftauchen, und so schnell zeichnen die auch nicht wirklich. Ich denke das manuelle Plotten in ein Widget ist da besser geeignet.

MfG,
FaS

[bw1faeh0]

naja, also ich habe festgestellt, dass das Plotten in einem Fenster nicht die Wucht ist (geschwindigkeitstechnisch)

Die Kommunikation zwischen der Hauptanwendung (die die Daten produziert, bzw. von der Hardware sammelt) und der Ausgabekonsole über Sockets laufen zu lassen kam mir dann gestern abend auch.

Ein Vorteil wäre da noch, dass die Ausgabe auf nem anderen Client laufen könnte, der nicht direkt mit dem Daten sammelnden Client zusammen hängt.