Warten auf ...? MsgWaitForMultipleObjects

[negaH]

Du musst den kompletten Messagequeue nach einem Signal leeren, ansonsten könnte es vorkommen das die eine Message die du mit Peekmessage entfernst eine neue Message postet. In diesem Moment muß MsgWaitForSingleObject() immer wieder sofort zurückkehren, da ja eine Message im Queue ist.

Delphi-Quellcode:

procedure Test;
var
  Msg: TMsg;
begin
  WriteLn('Start');

  while True do
    case MsgWaitForMultipleObjects(0, PDWord(nil)^, False, 100, QS_ALLEVENTS) of
      WAIT_OBJECT_0:
        if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then
//        while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
          case Msg.Message of
            WM_QUIT: WriteLn('Quit');
          else
            begin 
              WriteLn('Message');  
              TranslateMessage(Msg);
              DispatchMessage(Msg);
            end;
          end;
      WAIT_FAILED: WriteLn('Failed');
      WAIT_TIMEOUT: WriteLn('Timeout');
    end;

  WriteLn('End');
end;

Obiger code funktioniert bei mir. Stimmt, mit dem Threadhandle als Event gibt er WAIT_FAILED zurück. Damit ist mein vorletztes Posting falsch.

Bei mir gibt obiger Source in meiner Console aus:

Start
Message
Message
Timeout
Timeout
Message -> bewegte Mousecursor
Timeout
Timeout
Timeout
Message -> Idle message wm_Timer

usw. usw.

Wenn der Timeout zu groß ist dann kann dieser nicht mehr eintreten da in normalen Applications das OS weakup Messages versendet, zB. wm_SysTimer.



Gruß Hagen

[negaH]

@jbg

Zitat:

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

Tja ich weiß nicht so recht. Woher hast du diese Informationen ??

Ich gehe mal von der Logik aus.
PeekMessage() schaut nur im Queue nach ob eine Message vorhanden ist und liefert diese zurück. Damit könnte das OS also ein Flag pro Thread verwalten (zB. Zähler) um anzuzeigen das Messages im Queue sind. PeekMessage() in einer Loop würde also die meiste Zeit dieses Flag pollen, sofort zurückkehren und dann wiederum sofort Pollen.

Bei GetMessage() hängt das von der Implementation ab. Da ich die nicht kenne muß ich Annahmen treffen.
Der günstigste Fall nimmt an das GetMessage() so wie oben arbeitet. Also Ereignissorientiert, schön.
Der ungünstige Fall nimmt an das GetMessage() mehr erledigen muß als nur Messages zu holen.
Das GetMessage() noch aus Win2.0 bekannt ist und demzufolge Kompatibilitätsrestriktionen unterworfen ist.
Das GetMessage() als Highlevel Funktion auf LowerLevel API zurückgreift und einfach in einer Loop per PeekMessage() pollt.

Es steht also 3 zu 1 das GetMessage() pollen KÖNNTE. Also nehme ich an das der schlechteste Fall der ist mit dem ich rechnen muß, also Polling. Nutze ich obigen Weg so stelle ich garantiert auf Ereignissorierntiert um egal ob underlaying GetMessage() pollt oder auf Events aufsetzt. Ich egalisiere den Fakt ob gepollt wird oder nicht.

Gruß Hagen

[Gast]

Danke Hagen.

Dein obiger Post war nicht wirklich falsch. Du hattest es ja nur vorgeschlagen

Aber du meinst, wenn ich sie dispatche dann klappt es - das muss ich mal probieren. TranslateMessage() muesste ich ja weglassen koennen, weil ich ja eh keinen Dialog an der Queue zu haengen habe. Ich teste aber vorsichtshalber beides.

Danke vorerst. Falls sich noch was ergibt, melde ich mich nochmal. Ich hatte auch schon an eine Message gedacht ... vonwegen PeekMessage wartet nicht, bis eine gesendete Message auch gepostet wurde und so ... aber ich ging davon aus, dass wenn ich sie nicht sende, wohl kaum "irgendjemand" anders das tut.

[negaH]

Hi Asserbad,

wenn deine Funktion fertig ist würde ich sie gerne sehen. Normalerweise sendet das OS periodisch Messages. Viele Windows Klassen nutzen einen SysTimer() der dann alle 500ms eine wm_SysTimer Message auslösst.

Setze ich Timeout auf 5000 dann kommt nie WAIT_TIMEOUT da in der Zwischenzeit wm_SysTimer o.ä. periodisch gepostet wurde.

Gruß Hagen

[Gast]

Wie gewuenscht, mein Code:

Delphi-Quellcode:

function MAC_Thread(pml: PMachineList): DWORD; stdcall;
var
  msg: TMsg;
begin
  while True do
    case MsgWaitForMultipleObjects(0, PDWORD(nil)^, False, 5000, QS_ALLEVENTS) of
      WAIT_OBJECT_0:
        if PeekMessage(msg, 0, 0, 0, PM_REMOVE) then
          case msg.message of
            SIGNAL_STOP:
              begin
{$IFDEF DEBUGGING}
                Writeln('MAC: Received STOP.');
{$ENDIF DEBUGGING}
                Exit;
              end;
          else
            DispatchMessage(msg);
          end;
      WAIT_TIMEOUT:
        begin
{$IFDEF DEBUGGING}
          Writeln('MAC: Timeout ... scanning for machines');
{$ENDIF DEBUGGING}
          PostThreadMessage(pml^.Dispatcher, SIGNAL_MACLISTUPD, 0, 0);
        end;
    end;
  result := 0;
end;

Es war tatsaechlich die Sache mit dem Entfernen aus der Queue. Uebrigens, ich bekomme bei 5sec einen Timeout!

Hier noch ein Workerthread:

Delphi-Quellcode:

function WorkerThread(x: Pointer): DWORD; stdcall;
var
  msg: TMsg;
begin
  while True do begin
    if PeekMessage(msg, 0, 0, 0, PM_REMOVE) then
      case msg.message of
        SIGNAL_STOP:
          begin
{$IFDEF DEBUGGING}
            Writeln('WRK: Received STOP.');
{$ENDIF DEBUGGING}
            Exit;
          end;
        SIGNAL_WRKSCANMAC:
          begin
{$IFDEF DEBUGGING}
            Writeln('WRK: Now scanning machine with index ', msg.wParam);
{$ENDIF DEBUGGING}
            DispatchMessage(msg);
          end;
      else
        DispatchMessage(msg);
      end;
    WaitMessage; // lay down to sleep ... until we receive a message
  end;
  result := 0;
end;

[negaH]

Zitat:

Es war tatsaechlich die Sache mit dem Entfernen aus der Queue. Uebrigens, ich bekomme bei 5sec einen Timeout!

Korrekt da es eine Theadfunktion ist und dort kein bescheuerte Windows-Klasse die wm_SysTimer=$0118 Message erwartet. So bald aber ein blinkender Cursor im Spiel ist wird mit Sicherheit ein wm_SysTimer ausgelösst.

Eine Frage: Du nutzt den Weg über PostMessages() an Threads um eine zügige Abarbeitung zu gewährleisten ?? Ich frage weil du damit Kernel und User Objecte mixt, obwohl es doch besser wäre bei Threads mit reinen Kernel zu arbeiten, sprich Events, Semaphore usw.


Gruß Hagen

[jbg]

Zitat von negaH:

@jbg

Zitat:

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

Tja ich weiß nicht so recht. Woher hast du diese Informationen ??

Debugging.

GetMessage ruft die gleiche interne Funktion auf, die auch WaitMessage aufruft. Und zu WaitMessage sagt das PSDK

Zitat:

The WaitMessage function yields control to other threads when a thread has no other messages in its message queue. The WaitMessage function suspends the thread and does not return until a new message is placed in the thread's message queue.

Sieht mir doch stark nach "nicht polling" aus.

Zitat:

PeekMessage() in einer Loop würde also die meiste Zeit dieses Flag pollen, sofort zurückkehren und dann wiederum sofort Pollen.

Das merkt man an der CPU Belastung. (Zusatzinfo: Application.ProcessMessages ruft auch nur PeekMessage in einer Schleife auf)

Zitat:

Der günstigste Fall nimmt an das GetMessage() so wie oben arbeitet. Also Ereignissorientiert, schön.

Es sieht danach aus und "fühlt" sich auch so an.

Zitat:

Der ungünstige Fall nimmt an das GetMessage() mehr erledigen muß als nur Messages zu holen.

Ja. Es macht mehr und zwar vor dem internen WaitMessage und danach. Was es da nun genau macht, habe ich mir nicht angeschaut. Es dürfte aber mit den Parametern und dem Auslesen der Message-Queue zu tun haben.

Zitat:

Das GetMessage() noch aus Win2.0 bekannt ist und demzufolge Kompatibilitätsrestriktionen unterworfen ist.

Zugegeben, damals gab es noch keine Threads, aber es wurde trotzdem Rechenzeit an andere Anwendungen abgegeben. Nach außen hat sich nichts geändert. Die Messageloop sieht auch immer noch so aus, wie sie zu Win 3.1 Zeiten war.

Zitat:

Das GetMessage() als Highlevel Funktion auf LowerLevel API zurückgreift und einfach in einer Loop per PeekMessage() pollt.

Das macht sie auf keinen Fall. Das ist eher das, was Application.ProcessMessages macht.

Zitat:

Es steht also 3 zu 1 das GetMessage() pollen KÖNNTE.

Habe ich das jetzt mit obigen Argumenten wiederlegt?

[negaH]

@jbg, ja haste, danke für die Infos.

Was ich eigentlich zeigen wollte ist der Punkt wie ich programmiere wenn ich nur Vermutungen anstellen kann (einfach keine Zeit oder Lust alles debuggen zu müssen

Das Resultat dieser Überlegungen führt dazu das es, egal in welchem Context, nicht mehr pollt, alles bestens also und auch gut.

Gruß Hagen