From 18ab0edb00aa09e398f7ee7a2a05ab764e77b03c Mon Sep 17 00:00:00 2001 From: "Dimitrie O. Paun" Date: Mon, 22 Sep 2003 19:35:03 +0000 Subject: [PATCH] Remove obsolete info about the service thread. Update x11 wrapping description, misc cleanups. --- documentation/architecture.sgml | 121 ++++---------------------------- 1 file changed, 14 insertions(+), 107 deletions(-) diff --git a/documentation/architecture.sgml b/documentation/architecture.sgml index a902a35064b..959f43c9a64 100644 --- a/documentation/architecture.sgml +++ b/documentation/architecture.sgml @@ -5,10 +5,6 @@ Basic Overview - - Written by &name-ove-kaaven; &email-ove-kaaven; - - With the fundamental architecture of Wine stabilizing, and people starting to think that we might soon be ready to @@ -144,41 +140,6 @@ - - The Service Thread - - The Wine server cannot do everything that needs to be done - behind the application's back, considering that it's not - threaded (so cannot do anything that would block or take any - significant amount of time), nor does it share the address - space of its client threads. Thus, a special event loop also - exists in each Win32 process' own address space, but handled - like one of the process' own threads. This special thread is - called the service thread, and does - things that it wouldn't be appropriate for the wineserver to - do. For example, it can call the application's asynchronous - system timer callbacks every time a timer event is signalled - (the wineserver handles the signalling, of course). - - - One important function of the service thread is to support - the X11 driver's event loop. Whenever an event arrives from - the X server, the service thread wakes up and sees the - event, processes it, and posts messages into the - application's message queues as appropriate. But this - function is not unique - any number of Wine core components - can install their own handlers into the service thread as - necessary, whenever they need to do something independent of - the application's own event loop. (At the moment, this - includes, but is not limited to, multimedia timers, serial - comms, and winsock async selects.) - - - The implementation of the service thread is in - scheduler/services.c. - - - Relays, Thunks, and DLL descriptors @@ -288,13 +249,6 @@ FIXME --> Module Overview - - written by (???) - - - (Extracted from wine/documentation/internals) - - KERNEL Module @@ -314,46 +268,20 @@ FIXME --> libraries to perform their own synchronization (initiated by calling XInitThreads()). However, Wine does not use this approach. Instead Wine performs its - own synchronization by putting a wrapper around every X - call that is used. This wrapper protects library access + own synchronization using the + wine_tsx11_lock() / wine_tsx11_unlock() + functions. This locking protects library access with a critical section, and also arranges things so that X libraries compiled without (eg. with global errno variable) will work with Wine. - To make this scheme work, all calls to X must use the - proper wrapper functions (or do their own synchronization - that is compatible with the wrappers). The wrapper for a - function X...() is calles - TSX...() (for "Thread Safe X ..."). - So for example, instead of calling - XOpenDisplay() in the code, - TSXOpenDisplay() must be used. - Likewise, X header files that contain function prototypes - are wrapped, so that eg. "ts_xutil.h" - must be included rather than - <X11/Xutil.h>. It is important - that this scheme is used everywhere to avoid the - introduction of nondeterministic and hard-to-find errors - in Wine. - - - The code for the thread safe X wrappers is contained in - the tsx11/ directory and in - include/ts*.h. To use a new (ie. not - previously used) X function in Wine, a new wrapper must be - created. The wrappers are generated (semi-)automatically - from the X11R6 includes using the - tools/make_X11wrappers perl script. - In simple cases it should be enough to add the name of the - new function to the list in - tsx11/X11_calls; if this does not - work the wrapper must be added manually to the - make_X11wrappers script. See comments - in tsx11/X11_calls and - tools/make_X11wrappers for further - details. + In the past, all calls to X used to go through a wrapper called + TSX...() (for "Thread Safe X ..."). + While it is still being used in the code, it's inefficient + as the lock is potentially aquired and released unnecessarily. + New code should explicitly aquire the lock. @@ -820,15 +748,6 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop. Wine/Windows DLLs - - Based upon various messages on wine-devel especially by Ulrich - Weigand. Adapted by Michele Petrovski and Klaas van Gend. - - - - (Extracted from wine/documentation/dlls) - - This document mainly deals with the status of current DLL support by Wine. The Wine ini file currently supports @@ -892,24 +811,12 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop. Clearly, there is no one rule-of-thumb regarding which - load-order to use. So, you must become familiar with: + load-order to use. So, you must become familiar with + what specific DLLs do and which other DLLs or features + a given library interacts with, and use this information + to make a case-by-case decision. - - - - what specific DLLs do - - - - - which other DLLs or features a given library interacts with - - - - - and use this information to make a case-by-case decision. - @@ -952,8 +859,8 @@ child1->popup->child2->child3->wnd1->child4->wnd2->desktop. For the future, the Wine implementation of Windows DLL seems to head towards unifying the 16 and 32 bit DLLs wherever possible, resulting in larger DLLs. They are stored in the - dlls/ subdirectory using the 16-bit - name. For large DLLs, a split might be discussed. + dlls/ subdirectory using the 32-bit + name.