nanogui: Thread: TIMERS

On 11 Jan 2006, at 15:11, Robbie wrote:
>  I believe the timer is not getting its share of slice and doing an  
> IO somehow (I'm still digging through the API) allows it its time.
> I've attached a pice of code that shows this. It may run for a time  
> or  it may not run at all.

Polling GrCheckNextEvent() and calling an 'idle' function every time  
you receive a GR_EVENT_TYPE_NONE is an unusual way of doing things.  
Because there isn't a delay of any sort in idle(), you'll end up  
calling it over and over as fast as possible using 100% CPU. Better  
to do a GrGetNextEvent() and wait for an event to come in.

Also, you use the value of timer_tid without initialising it. Chances  
are, gcc will initialise it to 0 for you, but it's not really a good  
idea to rely on that.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

The sample code it really just that, a sample. Even in this case I don't understand why that should be a problem. The loop is to continually check for events and the idle call has nothing to it except when the timer has expired. Also, this idle in intented to several other tasks when nothing is happening. If memory serve me right, I believe the reason I chose CheckNext, instead of GetNext if a delay  involved with GetNext. I stand corrected incase there is something I may have misunderstood from the API. ??  


 --- On Wed 01/11, Alex Holden < ####@####.#### > wrote:
From: Alex Holden [mailto: ####@####.####
To: ####@####.####
     Cc: ####@####.####
Date: Wed, 11 Jan 2006 15:30:59 +0000
Subject: Re: [nanogui] TIMERS

On 11 Jan 2006, at 15:11, Robbie wrote:
> I believe the timer is not getting its share of slice and doing an
> IO somehow (I'm still digging through the API) allows it its time.
> I've attached a pice of code that shows this. It may run for a time
> or it may not run at all.

Polling GrCheckNextEvent() and calling an 'idle' function every time
you receive a GR_EVENT_TYPE_NONE is an unusual way of doing things.
Because there isn't a delay of any sort in idle(), you'll end up
calling it over and over as fast as possible using 100% CPU. Better
to do a GrGetNextEvent() and wait for an event to come in.

Also, you use the value of timer_tid without initialising it. Chances
are, gcc will initialise it to 0 for you, but it's not really a good
idea to rely on that.

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

On 11 Jan 2006, at 15:47, Robbie wrote:
> Even in this case I don't understand why that should be a problem.  
> The loop is to continually check for events and the idle call has  
> nothing to it except when the timer has expired.

An infinite loop repeatedly querying the server as fast as possible  
and using up 100% CPU might cause the server to behave oddly.

> Also, this idle in intented to several other tasks when nothing is  
> happening. If memory serve me right, I believe the reason I chose  
> CheckNext, instead of GetNext if a delay  involved with GetNext. I  
> stand corrected incase there is something I may have misunderstood  
> from the API. ??

GrGetNextEvent() blocks until there is an event ready to deliver to  
the client. If you want your client program to periodically perform  
some background task, use a periodic timer to trigger it.

-- 
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer

: What's the story on timers (GrCreateTimer, GrdestroyTimer,...)? Are they
working?

Yes.  Note that there are only the above two timer APIs for
creating or destroying a seperate timer.  In some of your messages,
you imply callback functions etc.  These are for the GdXXX timer
functions, which are "engine-level" and not accessible to the
nano-X applications programmer.

: Could someone briefly give me an overview of how the timer system works?
I'm almost sure a timer is being created but it appears that the event is
never fired, if GsTimerCB is indeed the timer callback.

It's very simple: All timers work by sending a
GR_EVENT_TYPE_TIMEOUT event to the application
event queue.  You can create a periodic (continual) timer
using GrCreateTimer(), or you can wait just once for a
timer using GrGetNextEventTimeout().  A periodic timer
is terminated using GrDestroyTimer().

These API functions are simpler than those Alex originally
contributed, in that there is no option for whether a
timer created via GrCreateTimer is periodic.  It always is.
Should you want a one-shot timer, use GrGetNextEventTimeout,
or destroy the timer in the first event message.

Note, GsTimerCB is an internal function, used only with the GdXXX
routines internally.



: There is a dcumentation that there may be other timer event queued and the
client must be able to handle late timer events. Is this something the app
have to keep track of?

All this means is that the server may send a timeout event, and the
client may be off doing something.  If the client doesn't get around
to servicing the first event before the server generates another, then,
whaddya know, you've now got two timer events in the queue.

: I just took a look at the current CVS version of Microwindows, and it
appears that the integration of my improved timer code was never
completed. The demos for both timer types are there, and a modified
version of the core timer code for both timer types is there (though
oddly it replaces one function with a flag argument with two nearly
identical functions), but GrCreateTimer() doesn't have the flag
argument that lets you choose which timer type to use.

The timer code has been in Microwindows for some time, and
works.  There were two contributions for timers.  I ended up
simplifying the nano-X timer API (described above), and using
a very slightly modified version of Alex's internal timer-handling
code. (internally, we support one-shot and periodic timers, for
server use only).

: Polling GrCheckNextEvent() and calling an 'idle' function every time
you receive a GR_EVENT_TYPE_NONE is an unusual way of doing things.
Because there isn't a delay of any sort in idle(), you'll end up
calling it over and over as fast as possible using 100% CPU. Better
to do a GrGetNextEvent() and wait for an event to come in.

This comment by Alex is correct.  You are likely having strange issues
with the timer code, because you're buzz-looping on GrCheckEvent,
rather than hanging in GrGetNextEvent{Timeout}.  This could be
a bug in nano-X, in that the timeout code isn't handled correctly
durring Peek and CheckEvents.  Also, if you look closely at
the implementation, for certain reasons, in CheckEvent only,
timeout events are returned as no event (EVENT_NONE).
Thus, I heartily agree with Alex's advice.

Hopefully, this and Alex's comments clear up your misunderstanding
of timers.

Regards,

Greg

I am having some problems with timers.  The programs that I am working with are:

ftp://justdave.us/example.c

ftp://justdave.us/nxterm.c

Nxterm has been modified from the original to support linux console terminal type and to allow calling from another c program.  I have linked the programs together and everything works fine until nxterm exits back to the example program.  At that point the timers disappear and even if I re-establish them with the GrCreateTimer, they will never generate an event.  I'm probably doing something stupid in nxterm but I can't find the problem.

I'd appreciate any help anyone can offer.

thanks

dave

Dave -

The problem here is likely to do with signals, IIRC the
GrCreateTimer mechanism uses these on the client side.
You might comment out all signal() calls in nxterm.c to see
if this affects the behaviour, although I quickly checked and
couldn't see an obvious issue.  Also, set VTSWITCH=N
when compiling the server.  Are you running link app to server,
or seperately?  If linked, then there's the additional problem
of the server's signalling needs.

Regards,

Greg

I am having some problems with timers.  The programs that I am working with 
are:

ftp://justdave.us/example.c

ftp://justdave.us/nxterm.c

Nxterm has been modified from the original to support linux console terminal 
type and to allow calling from another c program.  I have linked the 
programs together and everything works fine until nxterm exits back to the 
example program.  At that point the timers disappear and even if I 
re-establish them with the GrCreateTimer, they will never generate an event. 
I'm probably doing something stupid in nxterm but I can't find the problem.

I'd appreciate any help anyone can offer.

thanks

dave

Hi,
       How to use Timers in microwindows and how to set call back function
to the timers.
        can any one give some idea.

Regards,
Mohan.