nanogui: GrCheckNextEvent blocks when app linked into server
Subject:
Re: [nanogui] GrCheckNextEvent blocks when app linked into server
From:
Jordan Crouse ####@####.####
Date:
27 Aug 2001 23:55:26 -0000
Message-Id: <01082717545101.06690@cosmic>
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!
