DLL's & Callbacks
Übersicht
BlitzMax, BlitzMax NG Allgemein
KlaasBetreff: DLL's & Callbacks |
 Mo, Sep 11, 2006 17:56Antworten mit Zitat 
|
|
|---|---|---|
|
Hallo Leute!
Ich bastel schon seit einer kleinen Ewigkeit herum um einen Fingerprintscanner mit hilfe eine DLL (grFinger) z betreiben. Im Prinzip klappt auch alles sehr gut! Wenn allerdings häufiger abfragen bzw. Callbacks gerufen werden kommt es immer wieder zu Illegal Memory Exceptions oder zu Programmabrüchen ohne jegliche Fehlermeldung. Ich habe bemerkt das hingegen zu der üblichen Seriellen Abarbeitung des Blitzcodes die Callbacks einfach irgenwann ausgeführt werden. D.h. zu irgendeinem Zeitpunkt bricht die übliche verarbeitung ab und führt zunächst den Callback aus. Soweit ja auch korrekt. Nun komme ich aber natürlich teilweise in arge Probleme wenn ich Resourcen habe die sich Hauptprogramm und Callback teilen. Z.B. eine globale Variable. Kann es dadurch zu den immer wiederkehrenden Programmabbrüchen kommen? Ich habe es nun soweit es geht vermieden Globale Objekte zu benutzen. Ich muß das ja aber tun weil ich sonst die eingehenden Daten nirgendwo hinschreiben kann. Auch habe ich die Garbagekollektion immer auf susbend gestellt solange ichmit der DLL aktiv arbeite damit nicht Objekte vernichtet werden die ich grade irgendwo im Callback brauche. ICh frage mich also ob es generelle Probleme mit Callbacks etc in BlitzMax gibt und wie man diese evtl umgehen könnte. Try und Catch fängt schon einen gewissen Teil ab versagt aber auch irgendwann. Hatte jemand von euch schonmal ähnliche Probleme? Weiß jemand was über die Abläufe die ich beschrieben habe? Sonst irgendwelche Ratschläge. Wenns dann irgend jemanden interessiert bin ich auch gerne bereit meine Sources frei rauszugeben! Interesse irgendwer!? |
||
|
Artemis |
Mo, Sep 11, 2006 18:14 Antworten mit Zitat
|
|---|---|---|
|
Da das ganze ja nie gleichzeitig laufen kann (außer Multithreading, was ich ausschließe) solltest du in den Callback-Funktionen die Variablen immer überprüfen.
Ansonsten zeig mal ein kleines Beispiel, damit wir gucken können, ob man das ändern kann. |
||
Dreamora |
Mo, Sep 11, 2006 18:25 Antworten mit Zitat
|
|
|---|---|---|
|
Callback dürfen in BM nur sehr kurz laufen, andernfalls bricht BM zusammen, da es nicht ThreadSafe ist. Da ist es dann egal ob irgendwelche Variablen geteilt werden oder nicht (das würde übrigens via VarPtr gehen wenn du ihn als Byte Ptr übergibst)
Illegal memory access ist ein Fehler, was du jedoch viel häufiger zu sehen bekommen wirst ist der GC:Set Membit Fehler. Spätestens wenn du den zu sehen bekommst, war dein Callback zu lange aktiv und BM hat sich verabschiedet. Wenn du das ganze also mit BM nutzen möchtest, musst du dir da eine Variante einfallen lassen, die keinerlei Callbacks auf BM Seite bringt. Tut mir leid, sicher nicht was du hören wolltest, aber BM verlangt Single Thread Arbeitsverhalten, zumindest im Moment, jeder versuch das zu parallelisieren garantiert dir einen Programmcrash. Und bevor jetzt jemand mit: "Dann nimm halt eines der Threading Module" kommt, die sind komplett wertlos. Die wurden von Leuten mit Single Core / Single Prozessor Systemen verbrochen die glauben nur weil sie ne Ahnung von Mutexes etc hätten, könnten sie MultiThreading in BM einbauen. Wenn man die nämlich auf einem richtigen Multithreading fähigen System startet, gehts normalerweise nur wenige Sekunden bis sich BM verabschiedet, da der GC wie erwähnt nicht Thread Safe is. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
Klaas |
Di, Sep 12, 2006 10:47 Antworten mit Zitat
|
|
|---|---|---|
|
Hi,
der Fehler "GC:Set Membit Fehler" ist mir noch garnicht untergekommen. Die eigentlichen Callbacks werden sehr schnell abgearbeitet. Daran kann es eigentlich nicht liegen. Ich versuche übrigens garnicht irgendwas zu paralelisieren. Es ist nur so das ich vom Gerät/DLL ja nunmal einen Callback bekomme wenn da jemand drauftippt. Okay, ich werd mal versuchen alles aus dem Callback zu schmeißen was nicht unbedingt da reingehört. Erstmal Danke, ich meld mich mal mit meinem Ergebniss wieder. |
||
Dreamora |
Di, Sep 12, 2006 13:05 Antworten mit Zitat
|
|
|---|---|---|
|
Naja "Ressourcen die sich Hauptprogramm und Callback teilen" ist schon Parallelisierung. Denn da BM zu keinem Zeitpunkt gefreezt wird, kann und wird es tendenziell geschehen, dass der GC und der Callback gleichzeitig darauf zugreifen.
Die einzige Möglichkeit ist, dass du es auf BM Seite geschickt machst. Code: [AUSKLAPPEN] Type TDataholder Field mem:Byte Ptr Method Delete() MemFree mem End Method End Type Global sharedObject:TDataholder = New TDataholder ' Erzeugen des Speichers für den Callback, sagen wir 200 bytes sharedObject.mem = MemAlloc(200) Wenn du jetzt deinem Callback einen Speicherblock geben willst, auf dem er Operiert, gibst du ihm den Byte Ptr sharedObject.mem Dieser wird vom GC nicht verwaltet. Insofern hast du dadurch die Möglichkeit dafür zu sorgen, dass nur darauf zugegriffen wird, wenns der Callback nicht tut. Zusätzlich ist durch die Delete methode von TDataholder garantiert das du kein Memoryleak hast. Denn wenn du sharedObject = null machst, wird der Speicher der dran hängt auch automatisch frei gegeben, so das du nicht ständig dran denken musst, freemem aufzurufen. Hoffe das hilft dir ein stück weit. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
Klaas |
Di, Sep 12, 2006 14:27 Antworten mit Zitat
|
|
|---|---|---|
|
Ja, danke ... das Hilft natürlich.
Wegen der GC. Ich setze diese immer auf susbend solange ich im Callback arbeite. |
||
Dreamora |
Di, Sep 12, 2006 14:34 Antworten mit Zitat
|
|
|---|---|---|
| Stimmt, das ist ja mittlerweile auch eine Möglichkeit. | ||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
Übersicht
BlitzMax, BlitzMax NG Allgemein
Powered by phpBB © 2001 - 2006, phpBB Group