nanogui: GrCheckNextEvent blocks when app linked into server
Subject:
Re: [nanogui] GrCheckNextEvent blocks when app linked into server
From:
Olaf Meeuwissen ####@####.####
Date:
28 Aug 2001 00:55:14 -0000
Message-Id: <87ofp1ypfd.fsf@frodo.epkowa.co.jp>
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
