bog@gssc.UUCP (Lee Boekelheide) (11/04/87)
I have a couple of questions for the X V11, Release 1 folks.
1. The C Language X Interface document states in 8.4.1.2, Common
Keyboard and Pointer Event Processing, that
XButtonPressedEvents and XButtonReleasedEvents have as button
detail in the field called button the "bitwise inclusive OR
of one or more of these button names: Button1, Button2,...".
I believe that this is wrong. I think the button field
simply has in it the button number (Button1, Button2,...) of
the button whose change of state caused the event. The
button numbers are just sequential numbers, not ORable bits.
Am I correct in thinking the document wrong?
2. In the sample server, there is (in the 4.2bsd version) a
complication between Dispatch, WaitForSomething and
ReadRequestFromClient that favors servicing requests from
clients that have complete requests in the buffers read by
ReadRequestFromClient.
This favoritism, induced through the flag variable
ClientsWithInput, ignores clients that have no full requests
in their buffers until all requests are serviced for those
clients that have complete requests.
Why this favoritism? What was the intent?
In our System V implementation, a read from a client might
produce a buffer much larger than a single request packet
written by a client. So, for instance, the client plaid,
which produces oodles of little request packets, ends up with
a BIG buffer with oodles of requests in it. The server then
scurries around servicing plaid to the exclusion of all other
clients until the buffer is empty, then services each client
once. Since one of those serviced will then be plaid again,
and plaid will have produced another BIG buffer with lots of
requests in it, the net effect is that plaid monopolizes the
server.
This seems inappropriate.
Is it perhaps that the 4.2bsd ReadRequestFromClient function
never reads in a single read() more than a packet as written
by the client? If that were so, then the favoritism, instead
of being global, merely leans towards servicing the client's
whole packet before switching to a new client, and seems more
reasonable.
Could anyone who knows something of the genesis of this
device please send me a paragraph or so about its origins.
Thank you.
Lee Boekelheide
Graphic Software Systems, Inc.
(503) 641-2200susan@DECWRL.DEC.COM (Susan Angebranndt) (11/10/87)
sequent!gssc!bog@decwrl (Lee Boekelheide) writes:
In the sample server, there is (in the 4.2bsd version) a
complication between Dispatch, WaitForSomething and
ReadRequestFromClient that favors servicing requests from
clients that have complete requests in the buffers read by
ReadRequestFromClient.
This favoritism, induced through the flag variable
ClientsWithInput, ignores clients that have no full requests
in their buffers until all requests are serviced for those
clients that have complete requests.
The flag ClientsWithInput is there so that the sample server can avoid
doing 'select()' at all costs. Even a non-blocking select() to find
out which clients have data pending is a heavy-weight operation. The
fairest (and simplest) algorithm we could come up with that avoided
select calls was to process all complete requests from each select
before doing the next select call. (We don't allow clients with
incomplete requests to be processed so that client doesn't monopolize the server.)
The results are okay with this scheme. Running 2 plaids on my
microvax, I can still type at an xterm and get a good response.
Is it perhaps that the 4.2bsd ReadRequestFromClient function
never reads in a single read() more than a packet as written
by the client?
No, like your System V implementation, ReadRequestFromClient reads in
as much as possible.
If your implementation of select() for System V isn't as costly as the
4.2 implementation, then you can alter the scheduler to check for
pending data more often.
Susan