[comp.sys.isis] isis_accept_events

ken@gvax.cs.cornell.edu (Ken Birman) (12/02/89)

I tracked down and fixed the bug that caused isis_accept_events(ISIS_BLOCK)
to block indefinitely, even if an event occurs.

Patches to clib/cl_isis.c:

LINE		          CONTENTS (OLD, NEW)
old 596	         int set_scheduler = 0, ran = 0;
new 596	         int set_scheduler = 0, ran = 0, sync_count = 0;

new 607	         if(t_waiting(&accept_events))
new 608	             ++sync_count;

old 711:	if(ran == 0 && async_accept_count)
old 712:	    t_sig_all(&accept_events, 0);

new 713:	if((ran == 0 && async_accept_count) || (ran && sync_count))
new 714:	    t_sig_all(&accept_events, 0);

ken@gvax.cs.cornell.edu (Ken Birman) (07/21/90)

X11 users have reported the following annoyance with ISIS.  To
write an X mainloop that deals with ISIS you want to do something
like this:
	forever
	{
		XFlushInput();
		isis_accept_events(0);
	}
This is because X doesn't have a routine that will know how long ISIS
wants to delay (ISIS has timers) and doesn't know that it should 
watch for input on the ISIS input channels.   Likewise, ISIS doesn't
know about X.  This loop is an infinite one, though, since both ISIS
and X are being used asynchronously.  

Now, since telling X about the ISIS input channels won't deal with the
issue of ISIS timers, if we want something to block here, it should
probably be ISIS.  But,
		isis_accept_events(ISIS_BLOCK);
would mean that ISIS won't notice button input events.  This 
motivates a new mechanism
		isis_accept_events(ISIS_TIMEOUT, struct timeval *tp);
which tells ISIS to BLOCK for at most the specified amount of time,
as in a call to select().  This mechanism will be in V2.1

With this loop, ISIS might fail to notice a mouse input but never for
longer than the timeout specified in the timeval.
	forever
	{
		XFlushInput();
		isis_accept_events(ISIS_TIMEOUT, struct timeval *tp);
	}

-- Ken

PS: You may be wondering why we don't use isis_input to call XFlushInput
when an X11 input channel has input data on it.

Really sophisticated X11 users are probably (painfully) aware that X
sometimes reads ahead on its input channels and stuffs the resulting
data into a "re-read" queue.  This means that even though ISIS could
be told to watch for IO available on the X input channels, there
would be situations where ISIS might block incorrectly instead of calling
calling XFlushINput, because ISIS would not know how to check one of 
X "pseudo" input channels.  There is a way to deal with this (see 
isis_pseudo_io()) but the loop given above is probably easier to understand.