Microsoft MVP성태의 닷넷 이야기
Windows: 189. WM_TIMER의 동작 방식 개요 [링크 복사], [링크+제목 복사]
조회: 606
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일

WM_TIMER의 동작 방식 개요

아래의 답변을 하다 보니,

Winform timer tick 안에서 enabled 제어
; https://forum.dotnetdev.kr/t/winform-timer-tick-enabled/429

이참에 정리하고 지나가야겠다는 생각이 들어 ^^ 이렇게 별도의 글로 기록을 남깁니다.




제 기억에, 예전에는 상당히 깊은 내용까지 문서로 있었던 것 같은데 근래에는 워낙 응용 레벨의 추상화가 깊어지다 보니 그런 부분까지는 이제 공개를 하지 않는 듯합니다. 어쨌든, 가능한 있는 자료 내에서 인용해보겠습니다.

About Messages and Message Queues - Queued Messages
; https://docs.microsoft.com/en-us/windows/win32/winmsg/about-messages-and-message-queues#queued-messages

In addition, multiple WM_PAINT messages for the same window are combined into a single WM_PAINT message, consolidating all invalid parts of the client area into a single area. Combining WM_PAINT messages reduces the number of times a window must redraw the contents of its client area.


여러 개의 WM_PAINT가 발생하면 하나의 메시지로 합쳐져 처리한다는 식인데요, Raymond Chen의 블로그에서 이에 대한 보다 상세한 설명을 찾아볼 수 있습니다.

Paint messages will come in as fast as you let them
; https://devblogs.microsoft.com/oldnewthing/20111219-00/?p=8863

There is a class of messages which are generated on demand rather than explicitly posted into a message queue. If you call Get­Message or Peek­Message and the queue is empty, then the window manager will look to see if one of these generated-on-demand messages is due, messages like WM_TIMER, WM_MOUSEMOVE, and WM_PAINT.

...

Then a message retrieval function finds that there are no incoming sent messages to be dispatched nor any applicable messages in the queue to be retrieved, it looks at these extra flags to see if it should generate a message on the fly.


(WM_PAINT, WM_MOUSEMOVE도 유사한 방식으로 처리하는데), WM_TIMER의 경우 시스템에 의해 시간이 만료된 경우, 그것을 표현하는 flag를 설정한다고 합니다. (개념상 그렇다는 것이지, 실제로 그렇게 플래그 처리를 하는 방식은 아니라고! 제 기억으로는 얼핏 메시지 큐에도 우선순위별로 나누어져 있다고 했던 글을 본 적이 있는 것 같습니다. 혹시 이에 대한 자세한 이력과 문서를 아시는 분은 덧글 부탁드립니다. ^^)

이후 메시지 루프를 처리하는 GetMessage/PeekMessage가 호출되고, 이때 처리할 메시지가 있다면 그것을 처리하고, 더 이상 처리할 메시지가 없다면 시스템의 timer flag를 보고 그 시점에 WM_TIMER를 생성해 큐에 넣어 자연스럽게 GetMessage/PeekMessage의 호출에서 그 메시지를 수신하게 됩니다.

이러한 설명에 대해서는 다음의 글에서도 하고 있습니다.

Even though mouse-move, paint, and timer messages are generated on demand, it’s still possible for one to end up in your queue
; https://devblogs.microsoft.com/oldnewthing/20130523-00/?p=4273

We all know that the generated-on-demand messages like WM_MOUSE­MOVE, WM_PAINT, and WM_TIMER messages are not posted into the queue when the corresponding event occurs, but rather are generated by Get­Message or Peek­Message when they detect that they are about to conclude that there is no message to return and the generated-on-demand message can be returned.

...

Note that this auto-generate can happen even though the queue is not empty, because the message filters control what messages in the queue can be returned.

...

Note that this algorithm is conceptual. It doesn’t actually work this way internally. In particular, the window manager does not literally talk to itself, at least not out loud.


따라서, 일반적으로는 메시지 큐가 비어 있어야 WM_TIMER, WM_MOUSEMOVE, WM_PAINT 등이 처리되지만 꼭 그런 것만은 아니라고 합니다. 이에 대한 사례가 Message Filter 조건을 걸어 GetMessage/PeekMessage를 호출하는 경우라고 하는데요, 메시지 큐에 이벤트가 있다고 해도 필터 조건에 걸려 반환할 이벤트가 없다면 그런 경우에도 WM_TIMER, WM_MOUSEMOVE, WM_PAINT가 처리될 수 있다고 합니다. (여기서도 다시 한번 강조하지만 개념적으로 그렇다는 것입니다.)

그런데 만약 다른 메시지는 없고 WM_TIMER만 발생하는 환경에서, 메시지 필터링으로 인해 WM_TIMER 처리가 제외된다면 어떻게 될까요? GetMessage/PeekMessage는 계속해서 조건을 만족하는 메시지가 없어 큐가 비어 있는 것과 유사한 동작을 할 것이고, 따라서 WM_TIMER가 지속적으로 메시지 큐에 차서 나중에는 더 이상 큐의 여유 공간이 없는 상황까지 가게 될 것입니다. 실제로 이런 조건이 COM 개체에서 발생할 수 있음을 다음의 글에서 보이고 있습니다.

Why is my message queue full of WM_TIMER messages?
; https://devblogs.microsoft.com/oldnewthing/20160624-00/?p=93745

COM 런타임은 WM_TIMER는 처리하지 않고 WM_SYSTIMER만 처리하므로 결국 COM 환경에서 WM_TIMER를 발생시키면 지속적으로 WM_TIMER 메시지가 큐에 차게 되고, 결국에는 일반 메시지까지 처리할 수 없게 되는 것입니다.

마지막으로 Raymond는 이런 글을 남기는데요,

Can I force a WM_TIMER message to be generated when the timer comes due, even if the message queue is not idle?
; https://devblogs.microsoft.com/oldnewthing/20191108-00/?p=103080

위의 글을 살짝 테스트해 보면 다음과 같은 WinForm 코드를 만들어 볼 수 있습니다.

using System;
using System.Runtime.InteropServices;
using System.Windows.Forms;

namespace WindowsFormsApp1
{
    public partial class Form1 : Form
    {
        [return: MarshalAs(UnmanagedType.Bool)]
        [DllImport("user32.dll", SetLastError = true, CharSet = CharSet.Auto)]
        internal static extern bool PostMessage(IntPtr hWnd, uint Msg, IntPtr wParam, IntPtr lParam);

        Timer _timer;
        System.Threading.Thread _thread;
        public Form1()
        {
            InitializeComponent();
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            _thread = new System.Threading.Thread(postMessageFunc);
            _thread.Start();

            _timer = new Timer();
            _timer.Interval = 1000;
            _timer.Tick += _timer_Tick;
            _timer.Enabled = true;
        }

        protected override void DefWndProc(ref Message m)
        {
            if (m.Msg == 0x0400 + 1)
            {
                System.Threading.Thread.Sleep(900);
            }

            base.DefWndProc(ref m);
        }

        private void postMessageFunc()
        {
            Control.CheckForIllegalCrossThreadCalls = false;
            while (true)
            {   // WM_USER == 0x0400
                PostMessage(this.Handle, 0x0400 + 1, IntPtr.Zero, IntPtr.Zero);
                System.Threading.Thread.Sleep(800);
            }
        }

        private void _timer_Tick(object sender, EventArgs e)
        {
            System.Diagnostics.Trace.WriteLine(DateTime.Now);
        }
    }
}

위와 같이 실행하면, _timer_Tick 이벤트가 발생하지 않습니다. 왜냐하면 PostMessage가 800ms마다 메시지를 큐에 넣어두고 메시지 큐를 비우는 스레드가 900ms 동안 중지되기 때문에 메시지 큐에는 항상 (WM_USER + 1)에 해당하는 메시지가 놓여 있어 WM_TIMER가 들어올 여지가 없습니다. 그런데, 사실 저 상황에서는 WM_TIMER뿐만 아니라 대부분의 메시지가 처리되지 않습니다. 대신, 저 상태에서 GetMessage/PeekMessage 호출을 추가하면 Raymond Chen이 설명한 "generated-on-demand message"의 처리 방식을 확인할 수는 있습니다. 그래서 다음과 같이 코드를 바꾸면,

[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool PeekMessage(out NativeMessage lpMsg, IntPtr hWnd, uint wMsgFilterMin, uint wMsgFilterMax, uint wRemoveMsg);

protected override void DefWndProc(ref Message m)
{
    if (m.Msg == 0x0400 + 1)
    {
        System.Threading.Thread.Sleep(900);

        /* 0x0113 == WM_TIMER */
        /* 0x0000 == PM_NOREMOVE */
        PeekMessage(out NativeMessage msg, IntPtr.Zero, 0x0113, 0x0113, 0x0000);
    }

    base.DefWndProc(ref m);
}

[StructLayout(LayoutKind.Sequential)]
public struct NativeMessage
{
    // ...[생략]...
}

PeekMessage의 Filter 조건으로 인해 WM_TIMER가 메시지 큐에 있는지 확인하지만, 위와 같은 상황에서는 당연히 큐에 없으므로 'timer flag' 설정에 따라 WM_TIMER가 메시지 큐에 새롭게 들어오게 됩니다. 그래서, 디버그 모드로 실행하면 다음과 같은 식의 출력을 확인할 수 있습니다.

2021-02-16 오후 7:11:35
2021-02-16 오후 7:11:49
2021-02-16 오후 7:11:53
2021-02-16 오후 7:11:57
2021-02-16 오후 7:12:02
2021-02-16 오후 7:12:07
2021-02-16 오후 7:12:13
2021-02-16 오후 7:12:20
2021-02-16 오후 7:12:27
2021-02-16 오후 7:12:35
2021-02-16 오후 7:12:44
2021-02-16 오후 7:12:54
2021-02-16 오후 7:13:06
2021-02-16 오후 7:13:19
2021-02-16 오후 7:13:33
2021-02-16 오후 7:13:49
2021-02-16 오후 7:14:08
2021-02-16 오후 7:14:27
2021-02-16 오후 7:14:50
2021-02-16 오후 7:15:16
2021-02-16 오후 7:15:44
2021-02-16 오후 7:16:15
2021-02-16 오후 7:16:51
2021-02-16 오후 7:17:30
2021-02-16 오후 7:18:15
...

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




참고로, 본문에 실은 예제의 경우 계속 실행 상태로 두면 (WM_USER + 1) 메시지가 쌓여 결국에는 60초 동안 응답할 수 없는 상태가 되어 (비주얼 스튜디오의 디버그 모드인 경우) MDA 예외까지 보게 됩니다.

Managed Debugging Assistant 'ContextSwitchDeadlock'
Message=Managed Debugging Assistant 'ContextSwitchDeadlock' : 'The CLR has been unable to transition from COM context 0x83004a80 to COM context 0x83004958 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.'




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]


donaricano-btn



[최초 등록일: ]
[최종 수정일: 3/28/2021 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 쓴 사람
 




1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12579정성태3/28/2021252오류 유형: 707. 중첩 가상화(Nested Virtualization) - The virtual machine could not be started because this platform does not support nested virtualization.
12578정성태3/27/2021255개발 환경 구성: 560. Docker Desktop for Windows 기반의 Kubernetes 구성 (2) - WSL 2 인스턴스에 kind가 구성한 k8s 서비스 위치
12577정성태3/29/2021423개발 환경 구성: 559. Docker Desktop for Windows 기반의 Kubernetes 구성 - WSL 2 인스턴스에 kind 도구로 k8s 클러스터 구성
12576정성태3/25/2021369개발 환경 구성: 558. Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성 (2) - k8s 서비스 위치
12575정성태3/24/2021284개발 환경 구성: 557. Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성
12574정성태3/28/2021361.NET Framework: 1030. C# Socket의 Close/Shutdown 동작 (동기 모드)
12573정성태4/21/2021367개발 환경 구성: 556. WSL 인스턴스 초기 설정 명령어
12572정성태5/17/2021301.NET Framework: 1029. C# - GC 호출로 인한 메모리 압축(Compaction)을 확인하는 방법파일 다운로드1
12571정성태4/1/2021329오류 유형: 706. WSL 2 기반으로 "Enable Kubernetes" 활성화 시 초기화 실패 [1]
12570정성태4/7/2021291개발 환경 구성: 555. openssl - CA로부터 인증받은 새로운 인증서를 생성하는 방법
12569정성태3/18/2021356개발 환경 구성: 554. WSL 인스턴스 export/import 방법 및 단축 아이콘 설정 방법
12568정성태3/18/2021201오류 유형: 705. C# 빌드 - Couldn't process file ... due to its being in the Internet or Restricted zone or having the mark of the web on the file.
12567정성태4/9/2021327개발 환경 구성: 553. Docker Desktop for Windows를 위한 k8s 대시보드 활성화 [1]
12566정성태3/24/2021326개발 환경 구성: 552. Kubernetes - kube-apiserver와 REST API 통신하는 방법 (Docker Desktop for Windows 환경)
12565정성태3/17/2021174오류 유형: 704. curl.exe 실행 시 dll not found 오류
12564정성태3/16/2021215VS.NET IDE: 160. 새 프로젝트 창에 C++/CLI 프로젝트 템플릿이 없는 경우
12563정성태3/16/2021219개발 환경 구성: 551. C# - JIRA REST API 사용 정리 (3) jira-oauth-cli 도구를 이용한 키 관리
12562정성태3/16/2021367개발 환경 구성: 550. C# - JIRA REST API 사용 정리 (2) JIRA OAuth 토큰으로 API 사용하는 방법파일 다운로드1
12561정성태3/12/2021278VS.NET IDE: 159. Visual Studio에서 개행(\n, \r) 등의 제어 문자를 치환하는 방법 - 정규 표현식 사용
12560정성태3/12/2021329개발 환경 구성: 549. ssh-keygen으로 생성한 개인키/공개키 파일을 각각 PKCS8/PEM 형식으로 변환하는 방법
12559정성태3/28/2021255.NET Framework: 1028. 닷넷 5 환경의 Web API에 OpenAPI 적용을 위한 NSwag 또는 Swashbuckle 패키지 사용파일 다운로드1
12558정성태3/28/2021421Windows: 192. Power Automate Desktop (Preview) 소개 - Bitvise SSH Client 제어 [1]
12557정성태3/28/2021153Windows: 191. 탐색기의 보안 탭에 있는 "Object name" 경로에 LEFT-TO-RIGHT EMBEDDING 제어 문자가 포함되는 문제
12556정성태3/9/2021164오류 유형: 703. PowerShell ISE의 Debug / Toggle Breakpoint 메뉴가 비활성 상태인 경우
12555정성태3/28/2021279Windows: 190. C# - 레지스트리에 등록된 DigitalProductId로부터 라이선스 키(Product Key)를 알아내는 방법파일 다운로드2
12554정성태3/28/2021367.NET Framework: 1027. 닷넷 응용 프로그램을 위한 PDB 옵션 - full, pdbonly, portable, embedded
1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...