WM_TIMER의 동작 방식 개요
아래의 답변을 하다 보니,
Winform timer tick 안에서 enabled 제어
; https://forum.dotnetdev.kr/t/winform-timer-tick-enabled/429
이참에 정리하고 지나가야겠다는 생각이 들어 ^^ 이렇게 별도의 글로 기록을 남깁니다.
제 기억에, 예전에는 상당히 깊은 내용까지 문서로 있었던 것 같은데 근래에는 워낙 응용 레벨의 추상화가 깊어지다 보니 그런 부분까지는 이제 공개를 하지 않는 듯합니다. 어쨌든, 가능한 있는 자료 내에서 인용해보겠습니다.
About Messages and Message Queues - Queued Messages
; https://learn.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 GetMessage or PeekMessage 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_MOUSEMOVE, WM_PAINT, and WM_TIMER messages are not posted into the queue when the corresponding event occurs, but rather are generated by GetMessage or PeekMessage 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.'
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]