Return to select.t CVS log

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

Annotation of 43BSDTahoe/new/X/doc/Usenix/select.t, revision 1.1.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.