message queue overflow?



  • Boris willst du hier ne DOS-Attacke auf dein eignes Programm starten? 😃

    WilMen 🙂



  • naja wie kann ich prüfen ob bereit ne message mit meine ID in der queue ist ? geht das? wenn eine drin ist soll er keine Postmessage machen

    Mit PeekMessage geht das. Allerdings vermutlich nur aus dem Thread dem das Fenster gehört, bzw. um dessen Message Queue es sich eben handelt. Guckst du MSDN.


  • Mod

    Es bleibt dabei: Die beste Methode ist es immer noch kene Nachricht zu versenden, wenn dies nicht nötig ist... und das bekommt man auch hin!



  • ok folgendes.. habe einen thread, welcher in einem best. itnervall daten liest und via message an ein fensts Postet. das fenster musst dann die message in eine grafik schmeisen. Wenn nun das fenster länger braucht als der thread intervall ist .. werden immer mehr message gepostest, obwohl das fesnter nich nachkommt mit neuzeichnen


  • Mod

    Habe ich schon mal gepostet:
    Pseudocode:

    Workerthread:

    if (DatenDa)
    {
       LockDatenBereich();
       DatenEinfügenin Übergabestruktur;
       if (!UIDatenReady)
       {
          UIDatenReady = true;
          PostMessage UIHatDaten an UI Thread;
       }
    }
    

    UI Thread:

    UIHatDatenMessageHandler()
    {
       // Dienächsten 4 Zeilen müssen schnell gehen, damit Workerthread nicht gebremst wird.
       LockDatenBereich();
       Daten aus Übergabestruktur lesen;
       UIDatenReady = false;
       UnlockDatenBereich();
    
       Invalidate(UIFenster);
    }
    

    Mit dieser Methode ist immer nur eine Message in der Queue!



  • interssant die variable UIDatenReady wird als refernz über die übergabestruktur vom thread aus bereit gestellt?

    Aber Martin, nehmen wir an die Invalidate(UIFenster); geht lang? dann kann der thread ja trozdem ne message schicken?

    das UIReady flag wird ja als kopie übergeben oder , das kann auch net gehen?

    kann ich SendMessageTimeout nich in thread verwenden?


  • Mod

    1. Invalidate geht nie lange!
    2. Macht es nichts, denn dann läuft eben eine neue Nachricht ein, und das ist doch OK. Aber eben nicht mehr, denn dann ist das Flag gesetzt.
    3. UIDatenReady ist natürlich eine globale/klassenbezogene Variable, mit der Daten zwischen Thread und UI ausgetauscht werden. Wo steht, dass dies eine Kopie ist?
    4. SendMessageTimeout und damit Deinen WorkerThread abbremsen? Was willst Du eigentlich? Schnell sein oder lahm? 🤡 Warum auf ein Timeout warten, wenn man gar keines benötigt.



  • servus martin, dachte das UIReady flag ist eine membervariabel des workerthread.. welche ich über die message verschicke.. d.h. ich muss die variable global für die workerthread klasse und fenster machen?

    naja der Thread hat einen intervall von minimal 1 sekunde... die datenaktualiierung im fenster wird sicher so bei 10ms liegen;) aber es kann ja mal unter umständen was hängen...

    ja und Sendmessagetimeout ist nicht geignet für trhead fenster kommunikation?

    nehmen wir an, mein intervall des leseoperation ist nie kleiner 1 sek, und ich würde dem SendMessagetimout 500millisekunden timerout gehben.. dann wäre das ganze ja schonmal syncron... was würde passieren wenn die prozedur in der Messagefunktion länger als 500ms geht? wird dann die funktion abgebrochen???


  • Mod

    BorisDieKlinge schrieb:

    servus martin, dachte das UIReady flag ist eine membervariabel des workerthread.. welche ich über die message verschicke.. d.h. ich muss die variable global für die workerthread klasse und fenster machen?

    Du hast doch irgendwo die Daten liegen, die Du austauscht. Pack das Flag dazu, esgehört ja zu den Daten.
    Was weiß ich wie Du Deine Klassen zusammenbaust. Ja genauso wie die CirticalSection, die benötigt wird, muss das Flag in irgend einer Form für beide Klassen zugänglich sein, d.h. nich unbedingt global! 😉

    BorisDieKlinge schrieb:

    naja der Thread hat einen intervall von minimal 1 sekunde... die datenaktualiierung im fenster wird sicher so bei 10ms liegen;) aber es kann ja mal unter umständen was hängen...

    Dan gibt es aber kein Problem mit dem Overflow. 2 PostMessage hintereinander liegen ja dann 2 Sekunden auseinander. Warum reden wir hier eigentlich? 🙄

    BorisDieKlinge schrieb:

    ja und Sendmessagetimeout ist nicht geignet für trhead fenster kommunikation?

    JA!

    BorisDieKlinge schrieb:

    nehmen wir an, mein intervall des leseoperation ist nie kleiner 1 sek, und ich würde dem SendMessagetimout 500millisekunden timerout gehben.. dann wäre das ganze ja schonmal syncron... was würde passieren wenn die prozedur in der Messagefunktion länger als 500ms geht? wird dann die funktion abgebrochen???

    Du missverstehst das Ganze. Das Problem ist, dass SendMesageTimeOut auf den Empfänger wartet. Grundsätzlich die Frage: Warum sollte der Workerthread auf irgendwas warten was er vermeiden kann?
    Nur mal so am Rande? 🕶



  • Du missverstehst das Ganze. Das Problem ist, dass SendMesageTimeOut auf den Empfänger wartet. Grundsätzlich die Frage: Warum sollte der Workerthread auf irgendwas warten was er vermeiden kann?

    Hab das schon verstanden, das in der Threadloop der thread hier:

    SendMessageTimout(......,500); //<-- WARTET
    

    wenn die operation in der messagefunktion des fesnter nur 10ms geht, dann muss der thread ja nur 10ms warten, wenn die operation da >=500ms dauert, dann warte der thread hier max. 500ms so ist er richtig oder?

    Aber was passiert in der messagefunktion > 500ms braucht, wird dann aprupt da abgebrochen? sorry für die fragen.. aber das interessiert mich jetzt 🤡 :schland:

    P.S.: was ist mit der

    SendMessageCallback funktion

    ich köntne doch damit ein message schicken.. und ein flag im trhead setzen der thread würde weiter arbeiten, allerdings wir nun erst nur wieder ne nachricht schicken wenn das falg resetet wird, undd as köntne iuch mit der SendAsyncProc tun? was meisnt martin.. oder spinn ich jetzt ganz??? :p :p

    void CALLBACK Reset(HWND hwnd, UINT uMsg, DWORD dwData, LRESULT lResult){
     boReady=true;
    }
    
    threadloop(){
    
    if(boReady){
    ::SendMessageCallback(hWnd,WM_USER+100,0,0L,Reset,0);
    boReady=false; 
    }
    
    }
    

Anmelden zum Antworten