Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uunet!mcsun!ukc!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.windows.x
Subject: Re: monopolizing the server???
Summary: Scheduling algorithm wrong
Keywords: YeildControl WaitForSomething
Message-ID: <7412@acorn.co.uk>
Date: 4 Jun 91 14:11:03 GMT
Article-I.D.: acorn.7412
References: <4713@alliant.Alliant.COM>
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 30

In article <4713@alliant.Alliant.COM> ama@alliant.alliant.com (Alan Amaral) writes:
>Looking at the code (Dispatch, WaitForSomething, ReadRequestFromClient) it
>looks like it's EASY to monopolize the server if your connection is fast
>enough because it doesn't seem to be doing what it should.
>
>[... some explanation deleted ...]
>
>If you've processed the max (10) requests for this client then go check for
>other clients.  If other clients have requests buffered then those requests
>get processed.  Ok, I'll concede that much.  If there ARE NOT any requests
>from other clients else then WaitForSomething gets called again.
>Unfortunately, WaitForSomething checks for ANY client having stuff buffered,
>and in the case of a fast application which almost always buffers more than
>10 requests at a time (i.e. plaid, ico) will resume processing THAT client
>BEFORE it will check for input for any other client because it set the
>appropriate bit in the ClientsWithInput vector...

Dead right.  Its been like this since at least R3, I think it was in R2 too.
(I was sure I reported a bug... but I may have just filed it for later
reporting :-(.

If you fix WaitForSomething plaid can no longer degrade input response in
the way you describe.  Several fixes are possible - you have to decide on
the correct semantics of the calls to the Block and Wakeup Handlers and, if
supporting XTESTEXT1 whether to call XTestProcessInputAction; I only call
either if the select can block.  Whether or not these are called
WaitForSomething *always* polls the various connections for activity or for
new connections whenever it is called.

John Bowler (jbowler@acorn.co.uk)