UINT SetTimer(
    HWND hWnd,    // handle of window for timer messages
    UINT nIDEvent,    // timer identifier
    UINT uElapse,    // time-out value
    TIMERPROC lpTimerFunc    // address of timer procedure
   );
Функция SetTimer. Вызвав её с нулевыми параметрами дискриптора окна и идентифекатора, но с указанием адреса функции - выполняет функцию в потоке, который вызвал SetTimer, через указанный uElapse промежуток времени. 
Вопрос: Как ведёт себя вызваший поток, когда срабатывает таймер? Он ведь в это время может выполнять какие-то инструкции, а необходимо непременно выполнить callback function...  Вообщем, как осуществляется выполнение callback-функции вызванной таймером?
Не могу пока  найти никакой информации по этому.

Это сообщение отредактировал(а) Lexicss - 19.2.2008, 16:14

Lexicss, 

  Сообщение WM_TIMER по любому попадет в очередь сообщений потока и дефолтный обработчик должен вывать калбэк, если очереди сообщений нет, то фиг вам будет, а не калбэк   

Rennigth, ну у меня ж lpTimerFunc = не NULL. 

Alexeis, 
Как я этот механизм понимаю:
Значит любой поток имеет дефолтный обработчик. И когда в очередь сообщений текущего потока попадает WM_TIMER, то этот дефолтный обработчик и вызывает callback-функцию.

Но я всё равно и не понял, как прерывается работа потока? Например, вызвал я SetTimer в главном потоке. Сработал таймер, обработчик спаймал WM_TIMER и тут же принялся выполнять колбэк-функцию, а когда выполнил, то вернулся снова к своим делам? Так что ли?

  Угу.

Если есть в потоке очередь сообщений, и поток в данный момент не занят чем либо еще то рано или поздно он поймает WM_TIMER и выполнит твою lpTimerFunc. Выролнение какого-то кода не прервется, если конечно не выполнять всяких Application.ProcessMessages.

Alexeis, 
Где-то я такое слышал что нельзя поток просто так взять и прерывать в случайный момент времени.

Добавлено через 7 минут и 14 секунд
Rennigth, 
Тогда смысл такой:
поток перебирает свою очередь и обрабатывает один за другим свои сообщения. т.о. и обрабатывает колбэк-функцию, когда добирается до WM_TIMER.

Т.е. никакого механизма с тревожным ожиданием потока здесь нет?

Получается, что если назначено окно, то вызывает API функция DefWindowProc если нет окна, то DispatchMessage

Есть ещё такое понятие как поступление APC-запроса в очеред с указанием адреса функции и параметра. 
В SetTimer и есть этот механизм?
Или здесь совсем нето. wm_timer сообщение в параметрах хранит адрес функции для обработчика?

Добавлено через 2 минуты и 49 секунд
Т.е. поток при срабатывании таймера не вводится в режим тревожного ожидания?
(хочу просто чётко с этим разобраться)

нет, этот механизм в таймерах ожидания и в очередях таймеров применяться afaik (Waitable Timer, Timer Queue)

Нет.


Да.



Если честно незнаю что ты имеешь ввиду под понятием "тревожного ожидания" 

Вообщем юзай SetTimer/KillTimer и не тревожся. Он не очень точный конечно, есть другие, более точные, например мультимедийный таймер, вот они уже работаеют по всяким прерываниям и т.д.(не особо знаю механизм), и тогда уже могут возникать проблемы и может понадобится подобие синхронизации...

MetalFan, как это можно проверить на примере?

Lexicss, что проверить? msdn уже нет доверия? )

в любом случае _нужно_ вызывать DispatchMessage. А она уже передаст или в калбек или в процедуоу окна. Как в подпрограмму

сначало необходимо создать очередь сообщений. вызвав GetMessage (PeekMessage)