Warten auf ...? MsgWaitForMultipleObjects

[Gast]

Kann mir jemand sagen, wie ich es einfach OHNE Angabe von Objekten hinbekomme eine Message-Queue aufzubauen? Ich will, daß der Thread nachdem eine Message gepostet wurde, bzw nachdem ein Timeout auftrat jeweils etwas macht. Wie geht das?

Wenn ich MsgWaitForMultipleObjects(0, PDWORD(nil) ...) mache, dann wartet er nur EINMAL. Ich brauche es aber in einer Schleife. Will heißen, daß dieses "Nullobjekt" danach scheinbar signalisiert ist :-/

Bitte um Antworten.

[jbg]

Warum nutzt du nicht einfach GetMessage oder PeekMessage im Thread? Windows erzeugt dann automatisch eine Message-Queue für den Thread.

[Gast]

Das ist mir bewußt. So mache ich es notgedrungen auch schon.

Aber ich will
1. Warten auf eine Message (die dem Thread sagt sich zu beenden)
2. In Intervallen die Rechner im Netzwerk listen.

Verstehst du jetzt das Problem? Klar kann ich pollen und dann warten. So kann ich zumindest 99%ige Auslastung verhindern. Allerdings verlängert dies die Zeit, die der Thread beim Schliessen bleibt. Deshalb würde ich die Methode gern mit o.g. Funktion erweitern.

[negaH]

Ohne Object ? ich nutze einfach ein Event := CreateEvent(); also Object.

Allerdings brauchst du dann auch nicht mehr mit Messages zu arbeiten, sondern kannst gleich im Thread auf ein TerminierungsEvent warten.
Der Weg über MsgWait...() ist schon richtig, im Gegensatz zu GetMessage() und PeekMessage(). Er reduziert die CPU Last erheblich da nun von Polling auf Eventorierntiert umgestellt wird.

Ähm, vielleicht geht ja MsgWaitForMultipleObjects(1, GetCurrentThread, ..); ?? Ich habs noch nicht probiert, aber so lange der Thread auf seine eigene Terminierung wartet, wartet er eigentlich vergeblich !!

Gruß hagen

[negaH]

Scheint zu gehen :)

Delphi-Quellcode:

procedure Delay(Milliseconds: Integer);
var
  Tick: DWord;
  Event: THandle;
begin
  Event := GetCurrentThread;
  Tick := GetTickCount + DWord(Milliseconds);
  while Milliseconds > 0 do
    case MsgWaitForMultipleObjects(1, Event, False, Milliseconds, QS_ALLINPUT) of
      WAIT_TIMEOUT: Exit;
      WAIT_OBJECT_0: WriteLn('Fails');
    else
      begin
        Application.ProcessMessages;
        Milliseconds := Tick - GetTickcount;
      end;
    end;
end;

Gruß Hagen

[Luckie]

Mal ne blöde Frage. Der Übergabe parameter ist vom Typ Integer. Und wenn du ihn in der Funktion benutzt castest du ihn nach DWORD. warum übergibst du nicht gleich ein DWORD? Macht auch mehr Sinn oder wie wartet man minus 7 Sekunden?

[negaH]

Delphi-Quellcode:

if DWord(-7) >= 0 then
  while (Dword(Milliseconds) > 0) or TRUE do ;

if (Milliseonds in [-MaxInt..+MaxInt]) and 
   (GetTickCount in [0..MaxCardinal]) and
    SourceCompiledWithDelphiAbove5 then 
  Writeln('WARNING: unterschiedliche Typen, beide Typen werden erweitert und Laufzeitfehler bringt Bereichsfehler');

Anders gesagt: wäre Milliseconds Type DWord dann könnte die letzte Zeile Milliseconds := Tick - GetTickCount, Milliseonds mit Wert < 0 errechnen. Somit würde die while Milliseconds > 0 do Schleife nur terminieren wenn Milliseconds exakt ZERO ist. Also muß Milliseconds Type Integer sein. Der TypCast nach DWord() wiederum soll die Compilerüberprüfung deaktivieren, sowohl den Compiler mit seiner Warnung der unterschiedlichen Integertypen die kombiniert werden, wie auch die Laufzeitfehler-überprüfung die wenn aktiviert einen Bereichfehler melden würde. Beide Überprüfungen SIND in diesem Falle schwachsinnig da selbst wenn Milliseconds Type Int64 wäre, 1. kein Mensch so lange Delays macht und 2. GetTickCount eh bei 2^32-1 überlaufen würde.
Andererseits müsste man den Code so umschreiben das er entweder eine zusätzliche lokale Variable nutz um korrekt umzurechnen, oder aber man musst in der while Schleife zusätzlich GetTickCount aufrufen. Nämlich

Delphi-Quellcode:

while Tick > GetTickCount do
  case MsgWait..(.., Tick - GetTickCount) of

Der Cast sichert also den Code ab, optimiert eine lokale Var weg bzw. einen unnötigen Aufruf von GetTickCount;


Also alles ok mit dem Source :) Gruß Hagen

[Gast]

@Hagen: Vielleicht klingt es nicht nur trivial, sondern ist es auch. Aber ich bekomme es nicht auf die Reihe. Vielleicht nur ein Schusselfehler?!

Es ist nicht möglich auf das Handle von GetCurrentThread() zu warten. Das habe ich auch schon gedacht gehabt (hätte ich auch dazuschreiben können ;)) ... das gibt WAIT_FAILED.
Auch mit CreateEvent() hatte ich es zum Zeitpunkt des Posts schon probiert. Doch vergeblich die Liebesmüh.

Wenn ich mit MsgWaitForMultipleObjects() auf ein echtes Objekt, oder mit der Anzahl 0 (und dereferenziertem NIL als zweitem Parameter) arbeite, dann wartet er einmal ... danach rasselt er nur noch durch. Selbst ein Manual-Reset Event, welches ich innerhalb der Schleife zurücksetzte hat nix gebracht. Also das eigentliche Problem hier lautet wirklich nicht "wie benutze ich eine Win32 API?" vielmehr geht es darum, wie ich die o.g. API zum laufen bekomme. Habe mal gegooglet und wie es scheint, gab es noch andere Leute mit meinem Problem.

Also von der Reihenfolger her sollten die Aufrufe etwa so aussehen

Code:

while true do
begin
  if MsgWaitForMultipleObjects(0, PDWORD(nil)^, True, 5000, QS_ALLEVENTS)<>WAIT_FAILED then
  if PeekMessage(msg, 0, 0, 0, PM_REMOVE) then
  case msg.Message of
  WM_QUIT: ...;
  end
  else
  begin
//    Eigentlicher Job ...
  end;
end;

[jbg]

Zitat:

Zitat von negaH

im Gegensatz zu GetMessage() und PeekMessage(). Er reduziert die CPU Last erheblich da nun von Polling auf Eventorierntiert umgestellt wird.

Bei PeekMessage stimme ich dir zu, aber GetMessage betreibt kein Polling.

[Gast]

Um es noch mal zusammenzufassen: Ich brauche eine Funktion wie WaitMessage ... aber mit Timeout!!!

@jbg: Stimmt, PeekMessage kehrt sofort zurück ... egal ob ne Message da war oder nicht!