Опасности сна в потоке с выборкой сообщений

Это перевод The dangers of sleeping on a UI thread. Автор: Реймонд Чен.

Если у вас есть поток, который владеет окном, то вам не следует использовать в нём функцию Sleep, потому что это приведёт к тому, что ваш поток перестанет отвечать на сообщения на время засыпания. Это также верно и для коротких задержек, вроде засыпания на несколько секунд, потом проверку чего-то и повторное засыпание. Как мы заметили ранее, опрос плохо влияет на производительность системы, не даёт ОС переходить в режим пониженного электро-потребления, а также плохо работает в сценариях с сервером терминалов. Если вы ждёте (idle) - то ждите. Если вы заняты - то сделайте свою работу, а потом ждите.

К сожалению, я часто вижу код вроде такого:

fQuit := False;
  while not fQuit do
  begin
    Sleep(2000);
    CheckIfSomethingHappened;
    while PeekMessage(Msg, 0, 0, 0, PM_REMOVE) do
    begin
      if Msg.message = WM_QUIT then
      begin
        fQuit := True;
        Break;
      end;
      TranslateMessage(Msg);
      DispatchMessage(Msg);
    end;
  end;

Заметьте, что этот цикл проводит две секунды без обработки сообщений. Люди ещё не сошли с ума, чтобы вставлять двухсекундные задержки в поток, который отвечает за UI, но они часто так делают в фоновых рабочих потоках, которые создают невидимые окна для упрощения межпроцессного или межпоточного обмена данными. Поскольку у потока нет видимого интерфейса, то задержки в несколько секунд невидимы пользователю.

Вот только это не так.

Если системе нужно сделать массовую рассылку сообщений, то ей придётся ждать пробуждения потока, чтобы обработать сообщение. В это время, компонент, который запросил рассылку, вынужден ждать. Например, пользователь может дважды щёлкнуть по документу, который для открытия требует обмена DDE. DDE процесс начинает работу с массовой рассылки сообщения WM_DDE_INITIATE, которое теперь тормозит на вашем окне. Ваше спящее окно только что создало новый баг "Windows иногда замораживается на случайное время".

Заметьте, что многие люди не осознают, что вызов CoInitialize (возможно неявно) для инициализации потока для модели STA создаёт скрытое окно, чтобы выполнять маршалинг. Соответственно, поток, который запущен в одно-поточном окружении (single-threaded apartment) обязан обрабатывать сообщения. Если вы это не сделаете, то это приведёт к загадочным тормозам системы из-за вашего висящего окна.

Но что если вы хотите заснуть на какое-то время в своём потоке с выборкой сообщений? Мы разбирали это не так давно.