alarm() on PC/MSoft (long)

[Michael Gesundheit]

---"John D. Gwinner" <gwinner at northnet.org> wrote:
>
> Michael:
> 
> Note: there's a solution here, but first some
background:
> 
> .... 
> > > Is there a message pump in the app?  SetTimer,
even
> > with a processor
> > > callback, won't work without a message loop, I
> > believe.
> > 
> > I'll verify it at the moment I finish this reply
but
> > I clearly read from MS Developers Network CDs
that it
> > is one of the two. Either a message loop in which
the 
> > application gets WM_TIMER message OR a function
call
> > back. If this does not work I don't know what to
do.
> > Some people claim that kaffe works fine under
cygnus
> > build. I hope they tried more then HelloWorldApp.
This
> > does not need any threads.
> 
> As I mentioned, it was an MSJ article: check out
Volume 12, number 3,
> "Under the Hood" by Matt Pietrek.  It's on the
October MSDN, if you've got
> that handy.
> 
> QUOTE:
> 
> With this quick review out of the way, consider a
question I’ve heard
> several times recently: "I’ve called SetTimer in a
program that doesn’t
> have any windows. Therefore, I set the timer to
call a function, rather
> than post a message to a window. However, my timer
callback (see Figure 1)
> is never called."
> 
> .... Fig 1 snipped
> 
> My immediate response is to ask if their program
has a DispatchMessage
> loop. They’ll reply that they shouldn’t need one.
After all, they told
> SetTimer to call their TIMERPROC rather than post a
message. The problem
> is that calling DispatchMessage isn’t optional if
you’re using timers. As
> you’ll see later, DispatchMessage is needed for
both varieties of timer
> notifications (that is, window messages and
callback functions).
> 
> .....
> 
> In reading the Remarks section of the 32-bit
SetTimer documentation,
> you’ll come across this: "When you specify a
TimerProc callback function,
> the DispatchMessage function simply calls the
callback function instead of
> the window procedure. Therefore, you need to
dispatch messages in the
> calling thread, even when you use TimerProc instead
of processing
> WM_TIMER."
> 
> UNQUOTE.
> 

I read today the same in MSDN CD-roms. The bottom
line is that, so far, it looks that there is no way
to have an async event for a Win process. This is so
fundamentaly basic that it is hard for me to belive.
I'll post a question on MS developers mailing lists.
I can't belive that nobody came up with a solution.

I talked today to a friend who works with NT kernel
and she told me that such facility is available in the
kernel. My instructor for NT kernel/drivers said that
the lack of these facilities are what makes NT very
much un-realtime.

I don't give up yet. I'll find it.

--Michael

_____________________________________________________________________
Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com