<<>> <> <> <> <> <<>> <<>> The X Window system version 11. This documents internals of the X software; For XTk information, see: XTkDoc.tioga For user information, see: X11Doc.tioga For client information, see: X11ClientsDoc.tioga For a list of messages, see: X11MessagesDoc.tioga This documentation file, X11ImplDoc.tioga is probably somewhat outdated when you read it. Why is it better than C XLib: Type safety of cedar Memory ownership absolutely simple for clients [you own what you can change] No memory freeing necessary Dispatch on multiple threads Supervision of dangerous grabs, timeout. Service feature = Union of connections sharing name space for x entities, eventual caching on service Queues are protected against infinite growth Internal structures are freed when windows are destroyd. More caching. Design considerations Main ideas Type safe access of the X protocol. Independence of threads and connections. Efficiency [costs] Efficiency of minimal functionality does not matter, there is no choice once usage of X is decided. We should consider difference in cost of provided functionality to minimum functionality. Cost of buffereing of events: Is in minimal set because X protocal makes no guarantee of order of replies and events. Unavoidable, even if programmed in C --> free. [procedure call, copy of events/replies] Cost of type-safe access of the X protocol Considerable but undisputed. 1 Memory allocation to pass REF and guarantee readonlyness. 1 monitored procedure call per request to enable usage from several processes. Lots of code [space / programmer time] to present reasonable types; 1 additional copy of each reply byte to detach interpreting replies from reading the wire. Cost of independence of threads and connections. Speed and memory --> surprisingly cheap If feature is NOT used: Multiple connections in minimal set because X protocal relies on it. By dispatching on multiple threads does NOT cost additional procedure calls if only one thread is used. Additional parameter of procedure and ~4 memory reference and conditional expression. No additional memory usage. 1 additional memory allocation per event for buffering if thread eats events slower than they are generated. If feature IS used: 1 procedure call, 1 conditional expression, 2 memory references per event per thread registered on window. Additional memory usage to store switching information linear in # of windows / handler / thread tripples. Allocation of stack per thread. Client programming complexity: Synchronization problems: Even without this feature an other connection could introduce asynchrounous threads -> no cost Benefit of independence of threads and connections. 1) Wedge reductions simplifies client code 2) Independent access of different events make it possible to combine different packages providing services on the same window which do not depend on each other. Guarantee If a client of Xl does not hand out its thread(s) or its connection(s), and, the client does not wedge if it is the only user of X11, and, all other programs are (cedar) type safe and no program SHARES Xl and no other program monopolizes the X server or makes X requests on resources created by this program => the client does not wedge. => timing wedges are removed, but wedges on illegal access of resources can not be prevented. Questions Should basic X types like font/window be used indirectly [mean: Cedar program uses REF's to the basic X types] to be able to cache more information? Shadow the structure? Cache parts? It sounds wonderfull, but I'm not sure what purpose it would serves. Should Xl allow access to the whole X protocol? or should it spy on all clients to unwedge bad situations? [is this possible?] or should it even police and prevent certain native X requests? Should it cache more information to reduce number of transmitted X requests of clients requesting information? [As it deals with graphic contexts] Should the native Cedar X access be compatible with C language XLib acceses?