Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!rutgers!ames!ucbcad!ucbvax!gssc.UUCP!bog
From: bog@gssc.UUCP (Lee Boekelheide)
Newsgroups: comp.windows.x
Subject: X V11 R1 Questions
Message-ID: <8711041852.AA03226@bog.UUCP>
Date: Wed, 4-Nov-87 13:52:29 EST
Article-I.D.: bog.8711041852.AA03226
Posted: Wed Nov  4 13:52:29 1987
Date-Received: Mon, 9-Nov-87 06:44:32 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 56

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-2200