FastSwitch

[EWeiss]

Hab da mehr oder weniger ein kleines problem mit meiner Library
Meine Plugins werden über einen Thread verwaltet und warten mit WaitForSingleObject 1 Sekunde lang bis das ThreadHandle zerstört wird.

Die Plugins können im VollBild mit den Tasten Up/Down vor oder zurück geschaltet werden.
Nun gibt es Leute die einfach nicht warten können und den Finger auf der Taste halten
das bedeutet das die Plugins dann innerhalb einer ms entladen und neu geladen werden.

Wie kann man das bewerkstelligen das in dieser zeit die DLL's ordnungsgemäß entladen/neugestartet werden können?
Ich für meinen Teil argumentiere damit das dies nicht der normale weg ist und einem Stresstest gleich kommt.

Gibt es da ne saubere Lösung zu?

gruss

[Union]

Blockiere doch die Tastatur für die Wartezeit.

[EWeiss]

Zitat von Union:

Blockiere doch die Tastatur für die Wartezeit.

Das wäre eigentlich ideal..
Ist das auch legitim? Was ist wenn die Anwendung aus unersichtlichen gründen abstürzen würde
dann ist die Tastatur blockiert oder?

Gibt es da irgendwo nähere Informationen?

Hmm eventuell mit BlockInput..
Lieber wäre mir dann nur die beiden Tasten zu sperren.
Aber ein Hook verursacht wieder AntiVirus Probleme .

gruss

[Furtbichler]

Ich entprelle das einfach mit einem Timer (ca. 50-100ms). Der Tastendruck startet den Timer (immer wieder) neu.
Der Timer selbst lädt dann das Plugin. Das bedeutet im echten Leben, das ...
1. das einmalige Drücken der Taste mit 50-100ms Verzögerung zu einem Ergebnis führt (kaum bzw. gar nicht spürbar)
2. das kontinuierliche Drücken überhaupt nichts bewirkt und erst beim Loslassen mit der o.g. Verzögerung das Plugin geladen wird.

Alternativ speicherst Du deine Plugins zwischen.

[EWeiss]

Zitat von Furtbichler:

Ich entprelle das einfach mit einem Timer (ca. 50-100ms). Der Tastendruck startet den Timer (immer wieder) neu.
Der Timer selbst lädt dann das Plugin. Das bedeutet im echten Leben, das ...
1. das einmalige Drücken der Taste mit 50-100ms Verzögerung zu einem Ergebnis führt (kaum bzw. gar nicht spürbar)
2. das kontinuierliche Drücken überhaupt nichts bewirkt und erst beim Loslassen mit der o.g. Verzögerung das Plugin geladen wird.

Alternativ speicherst Du deine Plugins zwischen.

Danke ist ne gute Idee
1 Sekunde für jedes Plugin sollte ausreichen.

Frohes Weihnachtsfest..

gruss

[Furtbichler]

Eine Sekunde ist aber happig. Wenn der Ladevorgang zu lange dauert, dann müssen sie vorher geladen werden (imho). Aber ich hab ja die Anwendung nicht vor mir, kann das also nur aus der Ferne (grob) beurteilen.

Du machst das schon.

Frohes Fest zurück.

[EWeiss]

Zitat von Furtbichler:

Eine Sekunde ist aber happig. Wenn der Ladevorgang zu lange dauert, dann müssen sie vorher geladen werden (imho). Aber ich hab ja die Anwendung nicht vor mir, kann das also nur aus der Ferne (grob) beurteilen.

Du machst das schon.

Frohes Fest zurück.

Wir haben es nun so gelöst..
Ob das elegant ist mag dahingestellt sein

Code:

        case Action.ActionType.ACTION_PAGE_UP:
          {
            var timeSpamVerif = DateTime.Now - _lastAction;
            if (timeSpamVerif.TotalSeconds >= 2)
            {
              _validAction = true;
            }
            else
            {
              _validAction = false;
            }
            if (FullScreen && CurrentAudioStream != 0)
            {
              Log.Debug("BASS: Switch to Previous Vis");
              if (_validAction)
              {
                _lastAction = DateTime.Now;
                VizManager.GetPrevVis();
              }
            }
            break;
          }

        case Action.ActionType.ACTION_PAGE_DOWN:
          {
            var timeSpamVerif = DateTime.Now - _lastAction;
            if (timeSpamVerif.TotalSeconds >= 2)
            {
              _validAction = true;
            }
            else
            {
              _validAction = false;
            }
            if (FullScreen && CurrentAudioStream != 0)
            {
              Log.Info("BASS: Switch to Next Vis");
              if (_validAction)
              {
                _lastAction = DateTime.Now;
                VizManager.GetNextVis();
              }
            }
            break;
          }

wobei die 2 Sek. nicht variabel sind was wiederrum einen Deadlock auslösen könnte
wenn die Plugins zu schnell geändert werden da ich nur einen Thread zur Verfügung stelle.
Ist also Zeit abhängig und von PC zu PC unterschiedlich.
Hmmmm...

In der IDE funktioniert es mit 1 Sekunde als Eigenständige Ausführung dann nicht mehr deshalb 2 Sek.
Aber auch das könnte zu Problemen führen.
Was gäbe es da noch für eine Möglichkeit.

Timer wollen die nicht warum auch immer...

Und auf Änderung bzw. addieren eines KeyUp Events wurde gemeckert.
Was eigentlich die eleganteste und richtige Lösung wäre da man dann gezwungen wäre diesen erst loszulassen
damit das nächste Plugin geladen wird.

gruss

[Namenloser]

Wie werden die Plugins denn geladen und entladen? Wenn jedes Plugin einfach eine zentrale Finalize-Routine hätte, die man vom Programm aus aufrufen kann, dann würde das Programn ja automatisch so lange blockieren, bis alles sauber aufgeräumt ist.

Bei statischen Wartezeiten bin ich immer sehr skeptisch... in 5 Jahren bremst die Konstante das Programm auf aktuellen Rechnern dann unnötig aus. Gleichzeitig kann es durch Paging usw. immer mal vorkommen, dass der Prozess doch länger braucht.

[EWeiss]

Zitat:

Wenn jedes Plugin einfach eine zentrale Finalize-Routine hätte

Die habe ich ja BassVis_Quit.. bzw. BassVis_Free
Aber das nutzt überhaupt nichts wenn 1000 mal in einer sekunde versucht wird ein neues Plugin zu starten.

Wenn der Thread sich beendet werden gleichzeitig 100 neu aufgerufen..
Ich weis nicht wie ich das verhindern kann innerhalb meiner DLL.

Zitat:

Bei statischen Wartezeiten bin ich immer sehr skeptisch... in 5 Jahren bremst die Konstante das Programm auf aktuellen Rechnern dann unnötig aus. Gleichzeitig kann es durch Paging usw. immer mal vorkommen, dass der Prozess doch länger braucht.

Die weigern sich halt einen Eintrag für die Wartezeit in den Konfigurations Dialog einzutragen
mit dem Argument um so mehr Einstellungen eingefügt würden um so schlechter käme der User damit zurecht.
Für mich hört sich das an als würden die User für Dumm erklärt.

gruss

[Namenloser]

Achso, dann verstehe ich das. Dann müsste es doch aber genügen, vor dem Aufruf der Finalize-Routine ein globales Flag auf False zu setzen und hinterher auf True. Und wenn die "Nächstes Plugin laden"-Methode aufgerufen wird, während das Flag False ist, dann bricht die Methode ab (oder wartet, bis das Flag wieder True ist). Natürlich noch threadsafe, das ganze. Läuft dann eigentlich auf ganz einfaches, normales Locking hinaus. Übersehe ich etwas?