[PATCH] mi: if we fail to process 100 input events due to a stuck EQ, terminate.

[Peter Hutterer]

On Sun, Apr 19, 2009 at 09:07:29PM -0700, Aaron Plattner wrote:
> Please don't.  Or at the very least, make this optional.  There are a
> number of reasons why the graphics driver would get stuck for long
> periods of time including ridiculous client requests (e.g. huge
> convolution filters), graphics cards hitting thermal slowdown
> thresholds, graphics "hardware" that's actually a simluation library,
> the server being stopped in a debugger, etc.

Fair enough. Is there any way to "reliably" detect the difference?
I don't think making this optional is particularly useful, so dropping it is
probably better.

Cheers,
  Peter

> On Sun, Apr 19, 2009 at 08:10:18PM -0700, Peter Hutterer wrote:
> > After > 100 stuck input events, the server is unlikely to recover. So print a
> > message to the log and terminate the server instead of requiring users to kill
> > the server themselves.
> > 
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > ---
> >  mi/mieq.c |    8 +++++++-
> >  1 files changed, 7 insertions(+), 1 deletions(-)
> > 
> > diff --git a/mi/mieq.c b/mi/mieq.c
> > index 0dedbee..c263114 100644
> > --- a/mi/mieq.c
> > +++ b/mi/mieq.c
> > @@ -182,11 +182,17 @@ mieqEnqueue(DeviceIntPtr pDev, InternalEvent *e)
> >                  ErrorF("[mi] EQ overflowing. The server is probably stuck "
> >                          "in an infinite loop.\n");
> >  		xorg_backtrace();
> > -		stuck = 1;
> > +		stuck++;
> >  	    }
> >  #ifdef XQUARTZ
> >  	    pthread_mutex_unlock(&miEventQueueMutex);
> >  #endif
> > +
> > +	    if (stuck >= 100)
> > +		FatalError("[mi] The last 100 input events could not be "
> > +			"processed. This is a bug.\n"
> > +			"Terminating server now. Please submit this log"
> > +			"file to http://bugs.freedesktop.org");
> >  	    return;
> >          }
> >  	stuck = 0;
> > -- 
> > 1.6.2.2.447.g4afa7