| |
| |
|
Jac
de
Lad | Hallöchen, ich hab mal wieder ne komplizierte Fräge:
Ich will ein Prog schreiben, dass geleichzeitig einen komplexen Befehl einer DLL startet und aber noch weiterläuft, geht das? Ich habs mit der Thread.pcu versucht, klappt nicht. Jetzt hab ich nur noch als letzte Rettung, dass die Funktion der DLL, die ich aufrufe einen Thread kreiert, dieser dann eine andere Funktion der DLL aufruft, die was auch immer komplexes unternimmt und sich dann mit einem Rückgabewert beendet (während die komplexe Funktion noch werkelt). Das Prog bekommt den Rückgabewert (und die DLL ist immer noch am werkeln über die zweite Funktion), und kann weitermachen...wisst ihr was ich meine? 
Jac  |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 15.01.2006 ▲ |
|
| |
|
|
 | Ich denke mal nicht, das die Speicherverwaltung der Profan-Runtime Thread sicher ist, so das dort viel durcheinander gewirbelt werden könnte. Zumindestens müßtest Du CriticalSections (findeste in MSDN) definieren.
Die DLL arbeitet ja im Adreßraum Deines Programmes. Speicheradressen ändern sich, weil z.B. ein String grösser wird usw.
Kannste es ja probieren, aber ich denke mal, es wird nicht sicher funktionieren. |
|
| |
| |
| |
|
|
Jac
de
Lad | ähä, ich versteh nur Bahnhof. Mal sehen, vielleicht kann ich das Problem irgendwie lösen...
Danke!
Jac |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 15.01.2006 ▲ |
|
| |
|
|
 | Wenn es weniger auf die Performance angkommt - dann nutze einen neuen Prozess.
Damit die Prozesse kommunizieren können hatte ich die Pipe-Unit gepostet.
Salve. |
|
| |
| |
| |
|
|
| Wenn Du eine Variable änderst, in Deinem Profan Code, so ändert sich evtl. auch die Speicheradresse dieser Variable. Sollte jetzt der Thread, der auch in Deinem Adressraum abläuft, auch wenn die Funktion in einer DLL steht, dieselbe Speicheradresse verwenden, weil er noch nicht weiß, das diese vom Hauptprogramm belegt worden ist, gibt es unschöne Effekte, bzw. Abstürze. Deshalb muß dafür gesorgt werden, das nur entweder der Thread oder die Profan-Runtime einen Speicherbereich benutzen. Dafür ist Profan aber nicht ausgelegt. Du kannst also nur die Speicherbereiche versuchen vor Überschreiben zu schützen, eben durch CriticalSection und Semaphoren.
Es wird also nicht Funktionieren. Es sind jederzeit Abstürze möglich. Das kann man schlecht austesten. |
|
| |
| |
| |
|
|
| @Thomas: Natürlich hast Du grundsätzlich recht - bedenke aber das XProfanprogramme eher in einer VM ausgeführt werden - was die Sache entweder a) schwieriger oder b) einfacher macht.
Ich tendiere zu (a+b)/2 lol. Einige Dinge sind sicherlich Threadsicher - ander hingegen nichtmal mit criticalsections absicherbar da dies Roland tun müsste. Grundsätzlich glaube ich ist die PrfRun32.Exe garnicht so sehr Threadunsicher.
Die Frage ist hier also wie Threadsicher ist das Delphikompilat PrfRun32.Exe. |
|
| |
| |
| |
|
|
| [quote:6f14876c3d=iF]
Die Frage ist hier also wie Threadsicher ist das Delphikompilat PrfRun32.Exe.[/quote:6f14876c3d]
Naja, wahrscheinlich überhaupt nicht. Die Runtime wäre ja als Threadsicheres Kompilat noch um einiges grösser, sieht man ja an Threadsicheren Sprachen, wo man dies Optional hat, z.B. FreeBASIC
Aber mit einem weiteren Process, der sogar dieselbe Runtime verwenden kann, und Deiner Pipe-PCU, sollte er sein Ziel doch erreichen  |
|
| |
| |
| |
|
|
Frank
Abbing | Hi,
das ist einfach zu lösen. Du musst nur den neuen Tread innerhalb der Dll aufrufen!
So öffnet z.B. die ProSpeed Sprite-Funktion einen neuen Thread und kehrt dann sofort zum Hauptprogramm zurück. Derweil arbeitet der Thread weiter, bis ein Impuls vom Hauptprogramm ihn irgendwann wieder stoppt/beendet.
Voraussetzung ist hier aber das Laden der Dll via UseDll. External kann nicht verwendet werden, weil die Dll danach sofort wieder aus dem Speicher entfernt wird. |
|
| |
| |
| |
|
|
| @Frank: Ich glaub er schreibt nicht an der DLL - er kann da nix drin aufrufen.  |
|
| |
| |
| |
|
|
Frank
Abbing | | Dann gibt es noch die Möglichkeit, selber eine Dll zu schreiben, welche die fremden Dll-Funktionen aufruft. Also mit zwei Dlls zu arbeiten. |
|
| |
| |
| |
|
|
| Sobald der Thread und das Hauptprogramm dieselben Variaben verwenden, gibts Probleme. Als Ersatz für Timerfunktionen, zur Sprite-Bewegung mag es ja funzen, aber wenn Daten manipuliert werden, ist es aus, da der Zugriff (locking) nicht gesteuert wird, was im Falle von Processen von Windows erledigt wird.
Da ein Thread nur einen Parameter entgegen nehmen kann, ist eine Bearbeitung nur mit lokalen Variablen kaum möglich.
In manchen Anwendungsfällen gibts wohl keine Probleme, aber wenn ein Thread dazu verwendet wird, wofür er da ist, das Hauptprogramm von längeren Berechnungen entlasten, dann geht das nicht, ohne eine Locking Funktion. |
|
| |
| |
| |
|
|
Jac
de
Lad | @iF + Frank: Doch, die DLL schreibe ich selbst, ich weiß nur noch nicht, wie ich das Thread kreiere...
@all: Mir ist heute eine simple wie wirkungsvolle Lösung eingefallen, die mein Problem behebt, aber danke der Hilfe.
@Frank: Hülfe, was ist mit dir denn passiert???
Jac |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 16.01.2006 ▲ |
|
| |
|
(909)
Deutsch
English
Français
Español
Italia