Ich starte zwei unterschiedliche Programme die beide meine DLL verwenden.
Die DLL befindet sich im jeweiligen Anwendungspfad und ist weder in Window noch darunter liegenden Pfade abgelegt.

Trotzdem zerstören diese meinen RenderThread wenn ein Programm geschlossen wird
und zwar immer den des noch offenen Programm (innerhalb der gerade verwendeten DLL)

Wie kann ich das verhindern?
Dürfte doch eigentlich nicht passieren.

Wie kann also eine andere Anwendung Terminate auslösen von gleicher aber unterschiedlich verwendeten DLL's in unterschiedlichen Pfaden.

markieren

Delphi-Quellcode:

      if WaitForSingleObject(VisTimer, 1000 {1sec}) = WAIT_OBJECT_0 then
      begin
        DoOnVisTimer;
      end else
        Terminate;

gruss

Wie äußert sich denn dieses Zerstören?

Zitat von Uwe Raabe:

Wie äußert sich denn dieses Zerstören?

In dem Terminate ausgeführt wird.

Da scheint ein problem mit WaitForSingleObject vorzuliegen.
Aber irgendwie unverständlich weil wie schon gesagt die DLL's in unterschiedlichen Pfaden liegen.

Andere Anwendungen sind davon nicht betroffen nur die welche die gleiche DLL verwenden.
Egal ob VB/Delphi oder sonst was.

gruss

Ist der Timer ein Shared Object? Named Timer oder sowas?

Zitat von Zacherl:

Ist der Timer ein Shared Object? Named Timer oder sowas?

VisTimer := CreateWaitableTimer(nil, False, 'BassVisTimer');

Kann ich jetzt nicht beantworten ob er Shared ist.. sorry!
Deshalb etwas mehr code da kannst du vielleicht erkennen ob dies der Fall ist.

zusammenfalten · markieren

Delphi-Quellcode:

procedure TVisDataThread.Execute;
const
  _SECOND = 10000000;
var
  qwDueTime: Int64;
  liDueTime: _LARGE_INTEGER;
  ErrMsg: string;
begin

  if VisTimer = 0 then
    Exit;

  // Create a negative 64-bit integer that will be used to
  // signal the timer 1/4 seconds from now.
  qwDueTime := -1 * (_SECOND div 4);

  // Copy the relative time into a LARGE_INTEGER.
  liDueTime.LowPart := DWORD(qwDueTime and $FFFFFFFF);
  liDueTime.HighPart := longint(qwDueTime shr 32);
  if MySetWaitableTimer(VisTimer, // handle to a timer object
                        TLargeInteger(liDueTime), // when timer will become signaled
                        FDelayMS, // periodic timer interval
                        nil, // pointer to the completion routine
                        nil, // data passed to the completion routine
                        False {flag for resume state}) then
    // Following sentences are repeated every FDelayMS interval all the time from initial
    // start up to program end.
    repeat
      // We need to re-adjust timer interval according to the parameter "DelayMS" of vis plug-in.
      // (in case we exchange vis plug-ins)
      if FDelayMSChanged then
      begin
        FDelayMSChanged := False;
        CancelWaitableTimer(VisTimer);
        MySetWaitableTimer(VisTimer, TLargeInteger(liDueTime), FDelayMS, nil,
          nil, False);
      end;

      if WaitForSingleObject(VisTimer, 1000 {1sec}) = WAIT_OBJECT_0 then
      begin
        DoOnVisTimer;
      end else
        Terminate;

      SuspendIfHalted;
    until Terminated
  else
  begin
    ErrMsg := SysErrorMessage(GetLastError);
    ShowErrorMsgBox(ErrMsg);
    Terminate;
  end;
end;

gruss

Zitat von EWeiss:

Zitat von Zacherl:

Ist der Timer ein Shared Object? Named Timer oder sowas?

VisTimer := CreateWaitableTimer(nil, False, 'BassVisTimer'); Kann ich jetzt nicht beantworten ob er Shared ist.. sorry!

Zitat:

If the named timer object exists before the function call, the function returns a handle to the existing object and GetLastError returns ERROR_ALREADY_EXISTS.

[MSDN]

Vermutlich also ja: Alle deine Instanzen teilen sich einen Timer.
Was machst du mit dem Timer am Programmende? Ein CloseHandle sollte eigentlich keine Probleme machen; wenn du ihn deaktivierst, würde das deinen Fehler erklären.

Außerdem:

Zitat:

When an auto-reset timer is signaled, only one waiting thread becomes schedulable.

[Sample]

Damit könnte eventuell ein weiterer Fehler auftreten, indem ein Thread in das Timeout läuft, weil immer andere Threads signalisiert werden.

Zitat:

Vermutlich also ja: Alle deine Instanzen teilen sich einen Timer.
Was machst du mit dem Timer am Programmende? Ein CloseHandle sollte eigentlich keine Probleme machen; wenn du ihn deaktivierst, würde das deinen Fehler erklären.

Danke. Hab wieder was dazu gelernt

Jo.. Ich schließe das Handle.

markieren

Delphi-Quellcode:

  if VisTimer <> 0 then
  begin
    if not Suspended then
      ThreadHalt;

    CancelWaitableTimer(VisTimer);
    CloseHandle(VisTimer);
  end;

Werde mal versuchen wie es sich verhält wenn ich auf CloseHandle verzichte.
Abgesehen von eventuellen Speicherlecks die dann wieder entstehen.

gruss

Zitat von EWeiss:

Werde mal versuchen wie es sich verhält wenn ich auf CloseHandle verzichte.
Abgesehen von eventuellen Speicherlecks die dann wieder entstehen.

Das Handle wird bei Programmende ohnehin freigegeben, aber besser ist es, das selbst zu machen. Das Problem ist aber CancelWaitableTimer und nicht CloseHandle.

Denn:

Zitat:

Use the CloseHandle function to close the handle. The system closes the handle automatically when the process terminates. The timer object is destroyed when its last handle has been closed.

http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Allerdings frage ich mich, ob es bei deinem Anwendungszweck überhaupt Sinn macht einen Namen für den Timer anzugeben. Warum machst du das? Denn viel sinnvoller wäre doch wohl mit unbenannten Timern unabhängig voneinander zu arbeiten, oder?

Nur wenn ich beides deaktiviere im Destroy wird das Rendern in der anderen Anwendung weitergeführt.

markieren

Delphi-Quellcode:

    CancelWaitableTimer(VisTimer);
    CloseHandle(VisTimer);

Hmm.. Das kann es aber nicht sein Oder?
Welche alternativen bleiben mir dann noch?
Ich benötige einen WaitableTimer damit die Anwendungen bei aktionen die das Plugin betreffen
Konfiguration und so weiter nicht hängen bleibt.

Zitat:

Allerdings frage ich mich, ob es bei deinem Anwendungszweck überhaupt Sinn macht einen Namen für den Timer anzugeben. Warum machst du das? Denn viel sinnvoller wäre doch wohl mit unbenannten Timern unabhängig voneinander zu arbeiten, oder?

Und das könnte mein Probelm beheben ?
Wenn das so einfach ist probiere ich es doch gleich mal


gruss

Zitat von EWeiss:

Jo.. Ich schließe das Handle.

markieren

Delphi-Quellcode:

  if VisTimer <> 0 then
  begin
    if not Suspended then
      ThreadHalt;

    CancelWaitableTimer(VisTimer);
    CloseHandle(VisTimer);
  end;

Werde mal versuchen wie es sich verhält wenn ich auf CloseHandle verzichte.
Abgesehen von eventuellen Speicherlecks die dann wieder entstehen.

Damit lässt du genau das Falsche weg
CloseHandle zerstört den Timer nicht, wenn es noch andere Handles darauf gibt.
Aber: CancelWaitableTimer schaltet ihn auf inaktiv, sodass der andere Prozess nicht mehr signalisiert wird.

Die saubere Lösung wäre es, einen privaten Timer zu verwenden. Also entweder kein Name oder ein privater Namespace.

Zitat:

The object can be created in a private namespace. For more information, see Object Namespaces.

[MSDN]

// EDIT: Zu langsam Ich hab nur den Beitrag von EWeiss gesehen gehabt.