Designproblem bei langer Operation

dEUs

Hi Leute,
ich hab hier ein kleines Designproblem und würde gerne eure Meinung dazu hören.
Folgendes Szenario:
Ich habe eine DLL, welche ein Funktion exportiert. Dieser Funktion wird der Name einer MP3-Datei übergeben. Die Funktion dekodiert die Datei (mittels einer Klasse) und führt danach noch eine Operation mit der dekodierten Datei aus. Danach kehrt sie zurück. Das ist natürlich schlecht, da das Programm solange stillsteht.
Das Dekodieren sollte natürlich in einem Thread geschehen, das bedeutet aber, dass der User die Operation, die danach erfolgt, von Hand aufrufen muss, was ich aber UNBEDINGT vermeiden möchte. Hat jemand eine Idee, wie der User die Operation nicht selbst aufrufen muss, das Dekodieren aber trotzdem in einem Thread abläuft?
Danke für eure Vorschläge.

DerAltenburger

Ruf doch die Operation als letztes in Execute() vom Thread aus!

(Oder setz ne Fertigmeldung ab an Programm)

Unix-Tom

Welches BS?

Unter Windows kannst du dem Hauptthread eine Message senden oder überprüfen on der Thread noch läuft.

Das gleiche gibt es unter Linux. Allerdings nicht im Standard sondern in den Implemetierungen.

Und jetzt nicht sage, daß DLL aus Windows kommt den dies ist nur eine Abkürzung und MS war so unverschähmt diese als SUFIX zu verwenden.

[ Dieser Beitrag wurde am 09.03.2003 um 18:46 Uhr von Unix-Tom editiert. ]

dEUs

Unix-Tom: winxp
Wenn ich das richtig verstehe, dann meinst du, ich soll meinem Programm ne Nachricht schicken, wenn der Thread beendet ist. Aber das würde ja bedeuten, dass der User, der meine DLL verwendet, daraufhin die nächste Operation aufrufen müsste ...

CMatt

Aber das würde ja bedeuten, dass der User, der meine DLL verwendet, daraufhin die nächste Operation aufrufen müsste ...

Warum muss der user igend was machen wenn dein Prog ne WM_MACH_DAS_NACH_DEM_DECODIEREN bekommt!?

dEUs

der user = der programmierer, der mit meiner DLL arbeitet

D*niel *chumann

Warum machst du die Operation nicht auch in dem Thread (am Ende)?

dEUs

Die Operation danach gehört nicht in diese Klasse, deswegen müsste ich nen thread machen, der das ungethreadede dekodieren und die operation enthält. das bedeutet aber, dass ich den thread jedes mal um diese dekodier-funktion rumbauen muss, wenn ich sie benutz ...
Hm ... Aber vielleicht könnte ich in die Dekodierfunktion nen thread einbauen, der bei beendigung ein flag auf true setzt. und erst wenn dieses flag auf true ist, wird im thread, der aussenrum gebaut ist die operation aufgerufen ... was haltet ihr davon?

frenki

Also, ich würde mir um den Thread keinen Kopf machen: Wenn der User einen Thread will, soll er selbst einen starten und deine Funktion von diesem aufrufen, ist ja nun wirklich Trivial.

Wenn du den Thread selbst machen willst: Wie wärs mit Callback-Funktionen? Ist IMHO sowieo immer bei längeren Operationen Sinnvoll, weil heutzutage eine Fortschrittsanzeige Standard sein sollte, und auch dafür Informationen zurückgegeben werden müssen, um diese darzustellen.

dEUs

Hm, ich glaub, ihr versteht nicht ganz, was ich will ...
Ich schreibe eine DLL. Dem Programmierer, der sie benutzt, liegt nur die DLL, eine Headerdatei mit den exportierten Funktionen und ein paar Definitionen und eine lib, zum einbinden der DLL ins Programm, vor. Wenn er jetzt meine Funktion MP3_Dec_And_Operation() aufruft soll eben auch das dekodieren UND die Operation ausgeführt werden. Die Callback für die Statusanzeige habe ich schon von anfang an drinne ...

verstehs noch nicht:

bla MP3_Dec_and_Operation () {
  Dec();
  Operation();
}

voila, zwei funktionen aufgerufen

dEUs

witzbold.
Genau so hab ichs ja im Moment! Dec ist die Funktion, die LANG dauert.

CMatt

ich verstehs nicht....

- Der user ruft ein funktion in der DLL auf
- Die funktion startet nen thread der ne datei deociert
- Decodierung ist fertig
- ?????????

Unix-Tom

Ich kapiere es auch nicht.
In DLLs sind oft funktionen die lange dauern.
Was macht der WIN-Coder. Er startet eine Thread welche die DLL lädt und die exportierte Funktion ausführt. Da ich davon ausgehe, da du eine DynLIB machst kannst du IMHO sowieso keine Klassen exportieren.
Wenn der Programierer dies nicht tut dann ist er selbst schuld und kann seine GUI nicht mehr bedienen.
Einen Thread würde ich in einer dll nicht starten da man dann nicht mehr so schön aufräumen kann wenn der Programmierer ohne dieses Thread zu beenden das Programm schließt.
Ich wüsste jetzt eigentlich auch keine Funktionen in einer DLL der MFC welche eine Thread startet. Insbesonders da das Programm dann auch mit der z.B. Multithreadversion der MFC gelinkt werden müsste.

dEUs

hm. Dass muss ich mir mal durchdenken ...