nanogui: Thread: GrCheckNextEvent blocks when app linked into server

Dear all,

I've run into a little problem when linking my application into the
server (0.89pre7).  The same behaviour can be seen with the logfont
demo in src/demos/nanox/.  The font names will not appear until the
application receives events.  If you carefully generate your events
you can control the speed at which font names appear.

When running in a client/server setup everything is hunky-dory, but
with the application linked into the server (-DNONETWORK), it waits
for events because GrCheckNextEvent eventually calls GsSelect(0L).

In GsSelect, the following piece of code blocks if GdGetNextTimeout
returns false, which it does if (!timeout && !timerlist).  That is,
for timeout == 0 && !timerlist.

	/* Set up the timeout for the main select(): */
	if(GdGetNextTimeout(&tout, timeout) == TRUE)
		to = &tout;
	else to = NULL;

	/* Wait for some input on any of the fds in the set or a timeout: */
	if((e = select(setsize+1, &rfds, NULL, NULL, to)) > 0) {

I've mucked around int GdGetNextTimeout and things work for me now but
in doing so I've also badly broken the spec for GrGetNextEventTimeout
and GrGetNextEvent.

How do I fix this _cleanly_?

Please CC as I'm not on the list.

BTW, it'd be nice if the archive were searchable!
-- 
Olaf Meeuwissen       Epson Kowa Corporation, Research and Development

On 27 Aug 2001, Olaf Meeuwissen wrote:
> BTW, it'd be nice if the archive were searchable!

Use the search box at the bottom of:
http://www.linuxhacker.org/nanogui/

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

Alex Holden ####@####.#### writes:

> On 27 Aug 2001, Olaf Meeuwissen wrote:
> > BTW, it'd be nice if the archive were searchable!
> 
> Use the search box at the bottom of:
> http://www.linuxhacker.org/nanogui/

Thanks!  I jumped in from the link at http://www.microwindows.org/ and
the home link on the page that gave me jumped back to where I came
from.  Not particularly helpful ;-(

-- 
Olaf Meeuwissen       Epson Kowa Corporation, Research and Development

It looks like you just need to add another case to the if statement to 
compensate for the fact that you are esentially calling a select() that 
should return immediately.  It seems that GdGetNextTimeout() is not handling 
the edge case of timeout being zero, so you should check for it yourself and 
set the resuting 'to' accordingly:

if (timeout == 0) 
to = 0;
else if (GdGetNextTimeout(&tout, timeout) == TRUE)
to = &tout;
else
to = NULL;

You could also add code to GdGetNextTimeout() to check for this situation, 
but be careful that you don't break any timer handlers when you do.  No time 
should be elapsed from any of the timers for a GrCheckNextEvent() or 
GrPeekEvent() call.

Jordan

On Monday 27 August 2001 00:27, Olaf Meeuwissen mentioned:
> Dear all,
>
> I've run into a little problem when linking my application into the
> server (0.89pre7).  The same behaviour can be seen with the logfont
> demo in src/demos/nanox/.  The font names will not appear until the
> application receives events.  If you carefully generate your events
> you can control the speed at which font names appear.
>
> When running in a client/server setup everything is hunky-dory, but
> with the application linked into the server (-DNONETWORK), it waits
> for events because GrCheckNextEvent eventually calls GsSelect(0L).
>
> In GsSelect, the following piece of code blocks if GdGetNextTimeout
> returns false, which it does if (!timeout && !timerlist).  That is,
> for timeout == 0 && !timerlist.
>
> 	/* Set up the timeout for the main select(): */
> 	if(GdGetNextTimeout(&tout, timeout) == TRUE)
> 		to = &tout;
> 	else to = NULL;
>
> 	/* Wait for some input on any of the fds in the set or a timeout: */
> 	if((e = select(setsize+1, &rfds, NULL, NULL, to)) > 0) {
>
> I've mucked around int GdGetNextTimeout and things work for me now but
> in doing so I've also badly broken the spec for GrGetNextEventTimeout
> and GrGetNextEvent.
>
> How do I fix this _cleanly_?
>
> Please CC as I'm not on the list.
>
> BTW, it'd be nice if the archive were searchable!

Jordan Crouse ####@####.#### writes:

> It looks like you just need to add another case to the if statement to 
> compensate for the fact that you are esentially calling a select() that 
> should return immediately.  It seems that GdGetNextTimeout() is not handling 
> the edge case of timeout being zero, so you should check for it yourself and 
> set the resuting 'to' accordingly:
> 
> if (timeout == 0) 
> to = 0;
> else if (GdGetNextTimeout(&tout, timeout) == TRUE)
> to = &tout;
> else
> to = NULL;
> 
> You could also add code to GdGetNextTimeout() to check for this situation, 
> but be careful that you don't break any timer handlers when you do.  No time 
> should be elapsed from any of the timers for a GrCheckNextEvent() or 
> GrPeekEvent() call.

This will also break GrGetNextEvent and GrGetNextEventTimeout.  The
problem is that when compiling with -DNONETWORK these two as well as
GrCheckNextEvent eventually call GsSelect with a timeout.  However,
for the first two a value of zero means that you want to wait until
there is an event while with GrCheckNextEvent you don't.  Because a
timeout value is of unsigned type, there is no way you can fix this
easily in a clean way (without breaking the API spec).

For the time being I've backed out all my mucking around in devtimer.c
and call GrCheckNextEvent with a 1 ms timeout.  Blech!
-- 
Olaf Meeuwissen       Epson Kowa Corporation, Research and Development

I see what you mean.  Nobody remembered that zero has a special meaning for 
select, so they used that as a "wait forever" flag.   

I stared at the code for a bit, and it would seem to me that we could change 
GsSelect() to use a signed value without damaging the API (since GsSelect() 
only lives in the server, and it is not directly accessable to any client 
apps).  I think that would probably be the best way to handle it.  Then we 
could move a "wait forever" to be -1, and a 0 to be a "return immediately" 
just like the select() wants.

Either that, or if Greg doesn't want to move to a signed integer, we could 
toss in a:

#define GR_WAITFOREVER   0x80000000

Because nobody would wait 2,147,483,648 seconds would they?

Jordan

But I think that you can still get around this and not break the On Monday 27 
August 2001 17:29, Olaf Meeuwissen mentioned:
> Jordan Crouse ####@####.#### writes:
> > It looks like you just need to add another case to the if statement to
> > compensate for the fact that you are esentially calling a select() that
> > should return immediately.  It seems that GdGetNextTimeout() is not
> > handling the edge case of timeout being zero, so you should check for it
> > yourself and set the resuting 'to' accordingly:
> >
> > if (timeout == 0)
> > to = 0;
> > else if (GdGetNextTimeout(&tout, timeout) == TRUE)
> > to = &tout;
> > else
> > to = NULL;
> >
> > You could also add code to GdGetNextTimeout() to check for this
> > situation, but be careful that you don't break any timer handlers when
> > you do.  No time should be elapsed from any of the timers for a
> > GrCheckNextEvent() or GrPeekEvent() call.
>
> This will also break GrGetNextEvent and GrGetNextEventTimeout.  The
> problem is that when compiling with -DNONETWORK these two as well as
> GrCheckNextEvent eventually call GsSelect with a timeout.  However,
> for the first two a value of zero means that you want to wait until
> there is an event while with GrCheckNextEvent you don't.  Because a
> timeout value is of unsigned type, there is no way you can fix this
> easily in a clean way (without breaking the API spec).
>
> For the time being I've backed out all my mucking around in devtimer.c
> and call GrCheckNextEvent with a 1 ms timeout.  Blech!

Jordan Crouse ####@####.#### writes:

> I see what you mean.  Nobody remembered that zero has a special meaning for 
> select, so they used that as a "wait forever" flag.   
> 
> I stared at the code for a bit, and it would seem to me that we could change 
> GsSelect() to use a signed value without damaging the API (since GsSelect() 
> only lives in the server, and it is not directly accessable to any client 
> apps).  I think that would probably be the best way to handle it.  Then we 
> could move a "wait forever" to be -1, and a 0 to be a "return immediately" 
> just like the select() wants.

Eh, I thought select() expects a struct timeval * and blocks on a null
pointer.  Don't you have to pass it a timeval with a zero time for it
to return immediately?

If you're considering changing the server internal interface, then
what about

  void
  GsSelect( GR_TIMEOUT timeout, GR_BOOL wait_till_hell_freezes_over )

and wrapping the call to GdGetNextTimeout in a little if-then-else
logic?  Like so

  if (timeout == 0 && !wait_till_hell_freezes_over) {
    tout.tv_sec = 0;		/* the compiler should have done this
    tout.tv_usec = 0;		   for you already, though */
    to = &tout;
  } else {
    if (GdGetNextTimeout(&tout, timeout) == TRUE)
      to = &tout;
    else
      to = NULL;
  }

That way you don't have to persuade Greg to move to signed integer
times.  Of course you'd have to change all callers (but you'd have
to do that anyway if you make "forever" to be -1).

Come to think of it, this is probably cleaner still

  to = &tout;
  if (timeout != 0 || wait_till_hell_freezes_over)
    if (GdGetNextTimeout( to, timeout ) == FALSE)
      to = NULL;

> Either that, or if Greg doesn't want to move to a signed integer, we could 
> toss in a:
> 
> #define GR_WAITFOREVER   0x80000000

Might as well make that ~0L

> Because nobody would wait 2,147,483,648 seconds would they?

BTW, that'd be milliseconds and I can't see why not.  It's not even a
month ;-)

> Olaf Meeuwissen mentioned:
> > Jordan Crouse ####@####.#### writes:
> > > It looks like you just need to add another case to the if statement to
> > > compensate for the fact that you are esentially calling a select() that
> > > should return immediately.  It seems that GdGetNextTimeout() is not
> > > handling the edge case of timeout being zero, so you should check for it
> > > yourself and set the resuting 'to' accordingly:
> > >
> > > if (timeout == 0)
> > > to = 0;
> > > else if (GdGetNextTimeout(&tout, timeout) == TRUE)
> > > to = &tout;
> > > else
> > > to = NULL;

BTW, under many compilers NULL == 0 ;-{

> > > You could also add code to GdGetNextTimeout() to check for this
> > > situation, but be careful that you don't break any timer handlers when
> > > you do.  No time should be elapsed from any of the timers for a
> > > GrCheckNextEvent() or GrPeekEvent() call.
> >
> > This will also break GrGetNextEvent and GrGetNextEventTimeout.  The
> > problem is that when compiling with -DNONETWORK these two as well as
> > GrCheckNextEvent eventually call GsSelect with a timeout.  However,
> > for the first two a value of zero means that you want to wait until
> > there is an event while with GrCheckNextEvent you don't.  Because a
> > timeout value is of unsigned type, there is no way you can fix this
> > easily in a clean way (without breaking the API spec).
> >
> > For the time being I've backed out all my mucking around in devtimer.c
> > and call GrCheckNextEvent with a 1 ms timeout.  Blech!
> 

-- 
Olaf Meeuwissen       Epson Kowa Corporation, Research and Development

On Mon, 27 Aug 2001 19:54:51 Jordan Crouse wrote:

> Either that, or if Greg doesn't want to move to a signed integer, we
> could 
> toss in a:
> 
> #define GR_WAITFOREVER   0x80000000
> 
> Because nobody would wait 2,147,483,648 seconds would they?


I've been with a lot of RTOS' with definitions like the following:

#define GR_WAIT_FOREVER   ((GR_TIMEOUT) -1)
#define GR_WAIT_NEVER     ((GR_TIMEOUT) 0)

The built in typecast gets rid of the need to use signed ints. The forever
is 0xFFFFFFFF ( 4,294,967,295 ), so you get even more milli-seconds that
you can wait for.  


Gary James
####@####.####

On Monday 27 August 2001 18:54, Olaf Meeuwissen mentioned:
>
> Eh, I thought select() expects a struct timeval * and blocks on a null
> pointer.  Don't you have to pass it a timeval with a zero time for it
> to return immediately?
>
Thats right.  I probably wasn't very clear before... in my mind I saw passing 
a timeval with a zero value, and it came out as "passing zero".  My bad... :)

> > Because nobody would wait 2,147,483,648 seconds would they?
>
> BTW, that'd be milliseconds and I can't see why not.  It's not even a
> month ;-)
>

You caught me at the end of the day.  I should be banned from writing e-mails 
after 3:00 PM.... :)

Jordan