nanogui: Thread: Dealing with timeouts...

Greg & NanoGUIers,

Since our programs run in the same process as the nano-X-server, I was
wondering if you had some suggestions with how to deal with timeouts.
I was thinking since we want to be real lightweight that we might
include it in the GsSelect(void) loop.  Some sort of function in the
NanoGUI API to insert timeouts so that when GsSelect calls select() it
will set the timeout to be configurable, and call the appropriate
function.

Something like:
struct Timeout {
	void * func_to_call;
	void * some_data; /* maybe a union here? */
	time_t how_log;
}

Then have an array of timeouts ordered on when they are due, and run
the select() in GsSelect, check for all the timeouts that are due, and
take it from there.  Basically I want that damned clock to spin
without moving my mouse!  Just joking, but more seriously we probably
should support this internally rather than starting to pull events out
of the main loop of Nano-X.  (This would be elemental if we were to
support any sort of animation running inside nano-X, unless we start
pulling these things out as processes..., but my thoughts are that
doing so would be "Bad News" for low CPU powered portables..., not to
mention the memory drain of fork; and allies)  (I'm not a big fan of
sig alarm either..., breaking execution != good idea)

Shane.

On Wed Mar 08, 2000 at 12:58:22PM +0000, ####@####.#### wrote:
> Greg & NanoGUIers,
> 
> Since our programs run in the same process as the nano-X-server, I was
> wondering if you had some suggestions with how to deal with timeouts.
> I was thinking since we want to be real lightweight that we might
> include it in the GsSelect(void) loop.  Some sort of function in the
> NanoGUI API to insert timeouts so that when GsSelect calls select() it
> will set the timeout to be configurable, and call the appropriate
> function.

Sounds like a good solution would be setitimer(2) with
a signal handler for SIGALRM that checks if updates are
needed, and if so redraws the parts of the screen that
need it.

 -Erik

--
Erik B. Andersen   Web:    http://www.xmission.com/~andersen/ 
                   email:  ####@####.####
--This message was written using 73% post-consumer electrons--

: Something like:
: struct Timeout {
: void * func_to_call;
: void * some_data; /* maybe a union here? */
: time_t how_log;
: }

Shane,
    This would be a good idea, except, on inspection, 
fltk completely handles timeouts, and in it's own way.
The reason the clock doesn't spin without running
the mouse is that I coded up a quick GetMessage,
because Microwindows doesn't have PeekMessage,
which is what fltk coded.  In that loop, fltk completely
handles timeouts itself.

So, the proper solution is to write PeekMessage,
rather than recode fltk.  (Basically, the porting issue
here is mostly Microwindows, since fltk already
runs on Win32, and Microwindows is supposed to
emulate Win32.  So really all the work is implementing 
the calls fltk makes, rather than rewriting fltk, which
can cause any number of unforseen side effects)

I will have a version of PeekMessage tonight.

Regards,

Greg