Return to select.t CVS log

Up to [CSRG BSD Unix] / 43BSD / contrib / X / doc / Usenix

Annotation of 43BSD/contrib/X/doc/Usenix/select.t, revision 1.1

1.1     ! root        1: .SH
        !             2: Select and Non-blocking I/O
        !             3: .PP
        !             4: Without select(2), building X would have been very difficult.
        !             5: It provides the only mechanism in
        !             6: .UX
        !             7: for multiplexing many requests
        !             8: in a single process.
        !             9: It is essential for the X server to be able to block while testing for work
        !            10: to do on any client connection and on the keyboard device.
        !            11: X will then wake up with the information
        !            12: required to determine which device or connection needs service.
        !            13: .PP
        !            14: In actual interactive use of X on a very fast display,
        !            15: select accounts for both the most CPU time and the most subroutine calls.
        !            16: Over an afternoon's use on this display, it
        !            17: accounted for more than 20% of the CPU time used.
        !            18: This is not surprising, since most use of the window system is generated by
        !            19: input events going to editors (in our environment), and output
        !            20: character echoing as well as clock and load monitor graphics calls.
        !            21: When not loaded, one would expect on the order of one select call
        !            22: per X request performed.
        !            23: In fact, there are approximately two X requests performed per select call.
        !            24: .PP
        !            25: One should remember that select's overhead diminishes as the load
        !            26: on the window system increases,
        !            27: both because you are likely to have many requests on a single connection,
        !            28: and because multiple connections may be processed on a single call.
        !            29: Profiling of the server when the display is loaded shows select using
        !            30: a much smaller percentage of the total CPU time.
        !            31: .PP
        !            32: Note that for the typical case under normal use, TWO system calls
        !            33: will be occurring where one might potentially do.
        !            34: In the output case (from a client),
        !            35: X will be blocked in select awaiting input (one call).
        !            36: It must then read the data from the client and process it (second call).
        !            37: Due to the shared memory described above, we are avoiding a write system
        !            38: call to the display.
        !            39: On input (keyboard or mouse),
        !            40: X will be blocked in select (one call).
        !            41: It then gets the input event out of the queue, determines
        !            42: which client should get the event, and writes it (second call).
        !            43: Again, we have saved a system call to read the data.
        !            44: Note that since buffering may occur on both input and output,
        !            45: the overhead per graphics operation performed will
        !            46: diminish as the load on the server goes up, since the server
        !            47: will perform more work for the same amount of overhead.
        !            48: .PP
        !            49: Optimally, select should be very cheap.
        !            50: On fairness grounds, one would like to see if more input from
        !            51: a different client is available
        !            52: after each X request.
        !            53: The original X request handler would check after every request for more
        !            54: requests.
        !            55: The current scheduler only checks for more input when all previously read
        !            56: data has been processed,
        !            57: and provides an approximately 30% reduction in X server overhead
        !            58: (all in the select and read system calls).

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.