nanogui: Thread: link app into server

A while back I remember someone telling me not to use GrCheckNextEvent but use GrGetNextEvent in my event loop.
It turns out that GrGetNextEvent will block for a considerible period of time and that appears to be where the problem is. 
I've changed back to GrCheckNextEvent and I can see all my thread running as expected, expecially my main application event loop.

Is this a favourable assessment?

Thanks.
 
> -----Original Message-----
> From: Robbie ####@####.####
> Sent: Wednesday, May 10, 2006 4:56 PM
> To: ####@####.####
> Subject: RE: [nanogui] LINK APP INTO SERVER
> Importance: High
> 
> 
> > -----Original Message-----
> > From: ####@####.####
> > Sent: Wed, 10 May 2006 16:46:01 -0400 (EDT)
> > To: ####@####.####
> > Subject: [nanogui] LINK APP INTO SERVER
> >
> >
> > Hi All,
> >
> > I've been trying to figure out how to use nanox with the option
> > LINK_APP_INTO_SERVER = y.
> >
> > I notice there is no nanox server app, so where do I start from?
> >
> > Could someone tell me how this is used and how to get started?
> >
> >
> 
> I would like to know the answer to this question, however let me add a
> description of a problem I'm having so you can get a wider scope.
> First, I ran two threads created from the main program prior to entering
> the event loop. I've been observing considerible delay and investigated
> that the two threads are running as expected, but the evant loop is
> running consideraply slower, someting in the order of a few seconds to
> minutes.
> This is quite  unusual considering I've changed the scheduler to SCHED_RR
> and all threads have the same priority.
> I later add another thread with the event loop and that did the same
> thing.
> 
> What could be the cause of this?
> Any suggestions anyone?
> 
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

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

: A while back I remember someone telling me not to use GrCheckNextEvent but
use GrGetNextEvent in my event loop.
: It turns out that GrGetNextEvent will block for a considerible period of
time and that appears to be where the problem is.
: I've changed back to GrCheckNextEvent and I can see all my thread running
as expected, expecially my main application event loop.
:
: Is this a favourable assessment?

No - GrCheckNextEvent will never block, thus your application
will use 100% CPU time, even when its not doing anything.  This
CPU sucking is not generally desireable.  Also, GrNextEvent is
supposed to block, possibly forever, until either keyboard, mouse,
or a programmatic timeout event occurs.

Regards,

Greg



: > > -----Original Message-----
: > > From: ####@####.####
: > > Sent: Wed, 10 May 2006 16:46:01 -0400 (EDT)
: > > To: ####@####.####
: > > Subject: [nanogui] LINK APP INTO SERVER
: > >
: > >
: > > Hi All,
: > >
: > > I've been trying to figure out how to use nanox with the option
: > > LINK_APP_INTO_SERVER = y.
: > >
: > > I notice there is no nanox server app, so where do I start from?
: > >
: > > Could someone tell me how this is used and how to get started?
: > >
: > >
: >
: > I would like to know the answer to this question, however let me add a
: > description of a problem I'm having so you can get a wider scope.
: > First, I ran two threads created from the main program prior to entering
: > the event loop. I've been observing considerible delay and investigated
: > that the two threads are running as expected, but the evant loop is
: > running consideraply slower, someting in the order of a few seconds to
: > minutes.
: > This is quite  unusual considering I've changed the scheduler to
SCHED_RR
: > and all threads have the same priority.
: > I later add another thread with the event loop and that did the same
: > thing.
: >
: > What could be the cause of this?
: > Any suggestions anyone?
: >
: > _______________________________________________
: > Join Excite! - http://www.excite.com
: > The most personalized portal on the Web!
: >
: >
: >
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: ####@####.####
: > For additional commands, e-mail: ####@####.####
:
: _______________________________________________
: Join Excite! - http://www.excite.com
: The most personalized portal on the Web!
:
:
:
:

 --- On Sun 05/14, Greg Haerr < ####@####.#### > wrote:
From: Greg Haerr [mailto: ####@####.####
To: ####@####.#### ####@####.####
Date: Sun, 14 May 2006 18:50:36 -0600
Subject: Re: [nanogui] LINK APP INTO SERVER


>: A while back I remember someone telling me not to use GrCheckNextEvent but
use GrGetNextEvent in my event loop.
>: It turns out that GrGetNextEvent will block for a considerible period of
time and that appears to be where the problem is.
>: I've changed back to GrCheckNextEvent and I can see all my thread running
as expected, expecially my main application event loop.
>:
>: Is this a favourable assessment?

>No - GrCheckNextEvent will never block, thus your application
will use 100% CPU time, even when its not doing anything. This
CPU sucking is not generally desireable. Also, GrNextEvent is
supposed to block, possibly forever, until either keyboard, mouse,
or a programmatic timeout event occurs.



One of my thread sets a flag to update the screen without an Expose event (blitting). In This case, since GrGetNextEvent blocks, that would be a bad choice because I'll never get around to reading this flag which is in my event loop. That's why I've used GrCheckNextEvent since it will not block and I can use it in my event loop. If there is a better mechanism, my ears are opened.

Thanks,
--Robbie

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

: since GrGetNextEvent blocks, that would be a bad choice because I'll never
get around to reading this flag which is in my event loop. That's why I've
used GrCheckNextEvent since it will not block and I can use it in my event
loop. If there is a better mechanism, my ears are opened.

GrGetNextEventTimeout

This will block for either an event or a specified # of ms.

Regards,

Greg