Re: SetWaitableTimer confusions
"George" <George@discussions.microsoft.com> wrote in message
news:08999D5D-3FC5-47F5-9546-683C58917584@microsoft.com
Manual reset handle, once signalled, remains signalled until reset
with SetWaitableTimer. Automatic reset handle resets to
non-signalled state as soon as a thread successfully finishes a wait
on it.
Why we need to use two status of a timer -- signalled and
un-signalled? What is the usage scenario?
As with any other waitable object (see e.g. CreateEvent) - you wait on
the handle with, say, WaitForSingleObject. This function returns only
when the handle becomes signalled. The object is called "waitable timer"
for a reason, you know.
My confusion is timer is
just an utility to be used to execute task repeatedly, who cares
about the signal or un-signal status?
Well, how do you believe you would associate a "task" with a waitable
timer?
Kernel waitable timer is a low-level object. Its only job is to become
signalled at a predetermined time, thus possibly allowing threads
waiting on it to proceed. Any higher-level functionality you will have
to build yourself.
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925