nanogui: Thread: Problem With GrGetNextEventTimeout()?


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Problem With GrGetNextEventTimeout()?
From: "Gil Glass" ####@####.####
Date: 6 Nov 2006 18:27:02 +0000
Message-Id: <6ECE57DF49376146B91A92A3C37EFC0E0247DE81@SJEXCH03.ds.jdsu.net>

Hello,

 

I am using Nano-X via Microwindows version 0.91 on an ARM platform.
Everything's been working fine but today I tried using the
GrGetNextEventTimeout() function only to find that, depending on the
timeout specified, it might never time out.  What I found is that, if my
timeout is set to greater than 59 milliseconds, the function doesn't
return until an event occurs.

 

To summarize, the following code snippet will go to completion and will
show an event 16 (GR_EVENT_TYPE_TIMEOUT) having occurred:

 

...

 

// Just look at the event queue.

GrPeekEvent(&event);

 

cout << "The event queue contains " << event.type << "." << endl;

 

// Wait for an event with timeout.

GrGetNextEventTimeout(&event, 59);

 

cout << "Event " << event.type << " was received." << endl;

 

...

 

However, this snippet will hang forever waiting for an event:

 

...

 

// Just look at the event queue.

GrPeekEvent(&event);

 

cout << "The event queue contains " << event.type << "." << endl;

 

// Wait for an event with timeout.

GrGetNextEventTimeout(&event, 60);

 

cout << "Event " << event.type << " was received." << endl;

 

...

 

Note that "60" can be replaced with any number greater than 60 and the
same thing occurs.

 

Is this a known issue with this version of the code?  Please inform.

 

Cheers,

Gil Glass

Senior Software Engineer

Telecom Field Services Division

JDSU

Germantown, MD, USA

+1 (240) 404-2551

 

Subject: Re: [nanogui] Problem With GrGetNextEventTimeout()?
From: "Greg Haerr" ####@####.####
Date: 8 Nov 2006 17:39:55 +0000
Message-Id: <059e01c7035c$e0bf81b0$0300a8c0@RDP>

> I am using Nano-X via Microwindows version 0.91 on an ARM platform.
Everything's been working fine but today I tried using the
GrGetNextEventTimeout() function only to find that, depending on the
timeout specified, it might never time out.  What I found is that, if my
timeout is set to greater than 59 milliseconds, the function doesn't
return until an event occurs.

I've looked at the source code, and can't see any
reason for this.  In particular, check the code
in _GrGetNextEventTimeout in nanox/client.c,
the timeout value is used to fill out a timeval
structure.

Are you running LINK_APP_INTO_SERVER? If
so, different code executes for this case.

Otherwise, looks like a kernel select/timeval issue.

Regards,

Greg

Subject: RE: [nanogui] Problem With GrGetNextEventTimeout()?
From: "Gil Glass" ####@####.####
Date: 8 Nov 2006 18:15:49 +0000
Message-Id: <6ECE57DF49376146B91A92A3C37EFC0E024CB1F3@SJEXCH03.ds.jdsu.net>

Thanks for the reply.

To answer your first question, the server is NOT linked to the app. So
the code in question is in srvmain.c, srvfunc.c, et. al.  Having said
that, I have found some new information:

If I understand the code correctly, GrGetNextEventTimeout() first checks
whether there is an event in the event queue then calls GsSelect() with
the selected timeout value. This appears in srvfunc.c.  GsSelect() then
sets up some file descriptors for input devices such as mice and
keyboards for use in Linux's select() function.  It then calls
GdGetNextTimeout() which, again if I understand it correctly, returns
the timer from its list with the shortest remaining duration to the
exclusion of any others.  Now, I'm calling GrGetNextEventTimeout() with
a value of 1000 ms BUT THERE APPEARS TO BE ANOTHER TIMER WITH A TIMEOUT
OF BETWEEN 49 OR 50 ms (and sometimes 1 ms and sometimes 7 ms and
sometimes others) THAT CONSISTENTLY TRUMPS MY 1000 ms TIMEOUT TIMER.
Linux's select() function is then called with this much shorter timeout
and, even though there's no event, a GR_EVENT_TYPE_TIMEOUT event is not
generated.

The code gets a little confusing for me at this point.  For the record,
it's not operating on a network so that will cause the NONETWORK gated
code to be compiled.

Sorry for being long-winded.  Does this clarity anything?

Cheers,
Gil


-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Wednesday, November 08, 2006 12:40 PM
To: Gil Glass; ####@####.####
Subject: Re: [nanogui] Problem With GrGetNextEventTimeout()?

> I am using Nano-X via Microwindows version 0.91 on an ARM platform.
Everything's been working fine but today I tried using the
GrGetNextEventTimeout() function only to find that, depending on the
timeout specified, it might never time out.  What I found is that, if my
timeout is set to greater than 59 milliseconds, the function doesn't
return until an event occurs.

I've looked at the source code, and can't see any
reason for this.  In particular, check the code
in _GrGetNextEventTimeout in nanox/client.c,
the timeout value is used to fill out a timeval
structure.

Are you running LINK_APP_INTO_SERVER? If
so, different code executes for this case.

Otherwise, looks like a kernel select/timeval issue.

Regards,

Greg

Subject: Re: [nanogui] Problem With GrGetNextEventTimeout()?
From: "Greg Haerr" ####@####.####
Date: 13 Nov 2006 18:26:22 +0000
Message-Id: <09e501c70751$3a3a6780$0300a8c0@RDP>

>  Now, I'm calling GrGetNextEventTimeout() with
a value of 1000 ms BUT THERE APPEARS TO BE ANOTHER TIMER WITH A TIMEOUT
OF BETWEEN 49 OR 50 ms (and sometimes 1 ms and sometimes 7 ms and
sometimes others) THAT CONSISTENTLY TRUMPS MY 1000 ms TIMEOUT TIMER.
Linux's select() function is then called with this much shorter timeout
and, even though there's no event, a GR_EVENT_TYPE_TIMEOUT event is not
generated.


Hmmm...  Make sure VTSWITCH=N, since the 
drivers/vtswitch.c code calls GdAddTimer to deal
with changing consoles when drawing.  You might
also grep for GdAddTimer and find any other
code that might create a timer.

For debugging, perhaps add some printf() code in 
the addtimer routine so you'll know what timers are
being created.

Keep me posted, we'll get this fixed

Regards,

Greg
,
Subject: RE: [nanogui] Problem With GrGetNextEventTimeout()?
From: "Gil Glass" ####@####.####
Date: 14 Nov 2006 16:29:01 +0000
Message-Id: <6ECE57DF49376146B91A92A3C37EFC0E02546FF6@SJEXCH03.ds.jdsu.net>

Aha!  It looks like, in my config file, VTSWITCH=Y!  Changing it to 'N'
fixes the problem.  I'm not sure why I would have done this in the first
place.  Can you briefly explain what "VTSWITCH" means?

Thanks for looking into this!

Cheers,
Gil

-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Monday, November 13, 2006 1:26 PM
To: Gil Glass; ####@####.####
Subject: Re: [nanogui] Problem With GrGetNextEventTimeout()?

>  Now, I'm calling GrGetNextEventTimeout() with
a value of 1000 ms BUT THERE APPEARS TO BE ANOTHER TIMER WITH A TIMEOUT
OF BETWEEN 49 OR 50 ms (and sometimes 1 ms and sometimes 7 ms and
sometimes others) THAT CONSISTENTLY TRUMPS MY 1000 ms TIMEOUT TIMER.
Linux's select() function is then called with this much shorter timeout
and, even though there's no event, a GR_EVENT_TYPE_TIMEOUT event is not
generated.


Hmmm...  Make sure VTSWITCH=N, since the 
drivers/vtswitch.c code calls GdAddTimer to deal
with changing consoles when drawing.  You might
also grep for GdAddTimer and find any other
code that might create a timer.

For debugging, perhaps add some printf() code in 
the addtimer routine so you'll know what timers are
being created.

Keep me posted, we'll get this fixed

Regards,

Greg
,
Subject: Re: [nanogui] Problem With GrGetNextEventTimeout()?
From: "Greg Haerr" ####@####.####
Date: 14 Nov 2006 18:28:30 +0000
Message-Id: <0c8901c7081a$99a94e10$0300a8c0@RDP>

>  Can you briefly explain what "VTSWITCH" means?

As I tried to explain below, this option allows the user
to hit Alt F1/F2 to switch between virtual consoles,
graphics mode and text consoles.

Regards,

Greg



-----Original Message-----
From: Greg Haerr ####@####.#### 
Sent: Monday, November 13, 2006 1:26 PM
To: Gil Glass; ####@####.####
Subject: Re: [nanogui] Problem With GrGetNextEventTimeout()?

>  Now, I'm calling GrGetNextEventTimeout() with
a value of 1000 ms BUT THERE APPEARS TO BE ANOTHER TIMER WITH A TIMEOUT
OF BETWEEN 49 OR 50 ms (and sometimes 1 ms and sometimes 7 ms and
sometimes others) THAT CONSISTENTLY TRUMPS MY 1000 ms TIMEOUT TIMER.
Linux's select() function is then called with this much shorter timeout
and, even though there's no event, a GR_EVENT_TYPE_TIMEOUT event is not
generated.


Hmmm...  Make sure VTSWITCH=N, since the 
drivers/vtswitch.c code calls GdAddTimer to deal
with changing consoles when drawing.  You might
also grep for GdAddTimer and find any other
code that might create a timer.

For debugging, perhaps add some printf() code in 
the addtimer routine so you'll know what timers are
being created.

Keep me posted, we'll get this fixed

Regards,

Greg
,

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.