André Hentschel : winedev: Remove information about wine-[pk]thread, and some small pieces of love.
Module: docs Branch: master Commit: babd6c94465a947c063a420168c237f29a2b235a URL: http://source.winehq.org/git/docs.git/?a=commit;h=babd6c94465a947c063a420168... Author: André Hentschel <nerv(a)dawncrow.de> Date: Thu Jan 20 19:24:32 2011 +0100 winedev: Remove information about wine-[pk]thread, and some small pieces of love. --- en/winedev-architecture.sgml | 2 +- en/winedev-kernel.sgml | 143 ++++-------------------------------------- 2 files changed, 13 insertions(+), 132 deletions(-) diff --git a/en/winedev-architecture.sgml b/en/winedev-architecture.sgml index 953c24c..bb8638b 100644 --- a/en/winedev-architecture.sgml +++ b/en/winedev-architecture.sgml @@ -172,7 +172,7 @@ Only available on AMD64 architectures. </entry> <entry> - Flat model, with 32 bit addresses. + Flat model, with 32/64 bit addresses. </entry> </row> <row> diff --git a/en/winedev-kernel.sgml b/en/winedev-kernel.sgml index c60f1f8..4381c96 100644 --- a/en/winedev-kernel.sgml +++ b/en/winedev-kernel.sgml @@ -43,12 +43,8 @@ the next stage in the startup sequence. See the beginning of this chapter for more information on this check and why it's necessary. You can find this code in <filename>loader/glibc.c</filename>. The result - of this check is an exec of either <command>wine-pthread</command> or - <command>wine-kthread</command>, potentially (on Linux) via the - <emphasis>preloader</emphasis>. We need to use separate binaries here - because overriding the native pthreads library requires us to exploit - a property of ELF symbol fixup semantics: it's not possible to do this - without starting a new process. + of this check is an exec of <command>wine</command>, potentially (on Linux) + via the <emphasis>preloader</emphasis>. </para> <para> @@ -57,12 +53,10 @@ impose a Win32 style address space layout upon the newly created Win32 process. The details of what this does is covered in the address space layout chapter. The preloader is a statically linked ELF binary which - is passed the name of the actual Wine binary to run (either - <command>wine-kthread</command> or <command>wine-pthread</command>) - along with the arguments the user passed in from the command line. The - preloader is an unusual program: it does not have a - <function>main()</function> function. In standard ELF applications, - the entry point is actually at a symbol named + is passed the name of the actual Wine binary to run along with the arguments + the user passed in from the command line. The preloader is an unusual program: + it does not have a <function>main()</function> function. In standard + ELF applications, the entry point is actually at a symbol named <function>_start()</function>: this is provided by the standard <command>gcc</command> infrastructure and normally jumps to <function>__libc_start_main()</function> which initializes glibc before @@ -87,10 +81,10 @@ regions of the address space so the dynamic linker does not map shared libraries into them, and once that is done loading the real Wine binary off disk, linking it and starting it up. Normally all this is - automatically by glibc and the kernel but as we intercepted this + done automatically by glibc and the kernel but as we intercepted this process by using a static binary it's up to us to restart the process. The bulk of the code in the preloader is about loading - <command>wine-[pk]thread</command> and + <command>wine</command> and <filename>ld-linux.so.2</filename> off disk, linking them together, then starting the dynamic linking process. </para> @@ -121,11 +115,9 @@ </para> <para> - Both the <command>wine-pthread</command> and - <command>wine-kthread</command> binaries share a common - <function>main()</function> function, defined in - <filename>loader/main.c</filename>, so no matter which binary is - selected after the preloader has run we start here. This passes the + The <command>wine</command> binary has a <function>main()</function> + function, defined in <filename>loader/main.c</filename>, so after the + preloader has run we start here. This passes the information provided by the preloader into <filename>libwine</filename> and then calls <function>wine_init()</function>, defined in @@ -207,7 +199,7 @@ ExitProcess( entry( peb ) ); <para> As already explained in previous chapter (see <xref linkend="arch-mem"> for the details), Wine creates every 32-bit Windows process in its own - 32 address space. Wine also tries to map at the relevant addresses what + 32-bit address space. Wine also tries to map at the relevant addresses what Windows would do. There are however a few nasty bits to look at. </para> @@ -669,117 +661,6 @@ if (res != ERROR_SUCCESS) return res; </sect2> <sect2> - <title>POSIX threading vs. kernel threading</title> - - <para> - Wine runs in one of two modes: either pthreads (posix threading) or - kthreads (kernel threading). This section explains the differences - between them. The one that is used is automatically selected on - startup by a small test program which then execs the correct binary, - either <command>wine-kthread</command> or - <command>wine-pthread</command>. On NPTL-enabled systems pthreads - will be used, and on older non-NPTL systems kthreads is selected. - </para> - - <para> - Let's start with a bit of history. Back in the dark ages when Wine's - threading support was first implemented a problem was faced - Windows - had much more capable threading APIs than Linux did. This presented a - problem - Wine works either by reimplementing an API entirely or by - mapping it onto the underlying systems equivalent. How could Win32 - threading be implemented using a library which did not have all the - needed features? The answer, of course, was that it couldn't be. - </para> - - <para> - On Linux the pthreads interface is used to start, stop and control - threads. The pthreads library in turn is based on top of so-called - "kernel threads" which are created using the - <function>clone(2)</function> syscall. Pthreads provides a nicer (more - portable) interface to this functionality and also provides APIs for - controlling mutexes. There is a <ulink - url="http://www.llnl.gov/computing/tutorials/pthreads/"> good - tutorial on pthreads</ulink> available if you want to learn more. - </para> - - <para> - As pthreads did not provide the necessary semantics to implement Win32 - threading, the decision was made to implement Win32 threading on top - of the underlying kernel threads by using syscalls like - <function>clone()</function> directly. This provided maximum - flexibility and allowed a correct implementation but caused some bad - side effects. Most notably, all the userland Linux APIs assumed that - the user was utilising the pthreads library. Some only enabled thread - safety when they detected that pthreads was in use - this is true of - glibc, for instance. Worse, pthreads and pure kernel threads had - strange interactions when run in the same process yet some libraries - used by Wine used pthreads internally. Throw in source code porting - using Winelib - where you have both UNIX and Win32 code in the same - process - and chaos was the result. - </para> - - <para> - The solution was simple yet ingenious: Wine would provide its own - implementation of the pthread library <emphasis>inside</emphasis> its - own binary. Due to the semantics of ELF symbol scoping, this would - cause Wine's own implementation to override any implementation loaded - later on (like the real libpthread.so). Therefore, any calls to the - pthread APIs in external libraries would be linked to Wine's instead - of the system's pthreads library, and Wine implemented pthreads by - using the standard Windows threading APIs it in turn implemented - itself. - </para> - - <para> - As a result, libraries that only became thread-safe in the presence of - a loaded pthreads implementation would now do so, and any external - code that used pthreads would actually end up creating Win32 threads - that Wine was aware of and controlled. This worked quite nicely for a - long time, even though it required doing some extremely un-kosher - things like overriding internal libc structures and functions. That - is, it worked until NPTL was developed at which point the underlying - thread implementation on Linux changed dramatically. - </para> - - <para> - The fake pthread implementation can be found in - <filename>loader/kthread.c</filename>, which is used to - produce the <command>wine-kthread</command> binary. In contrast, - <filename>loader/pthread.c</filename> produces the - <command>wine-pthread</command> binary which is used on newer NPTL - systems. - </para> - - <para> - NPTL is a new threading subsystem for Linux that hugely improves its - performance and flexibility. By allowing threads to become much more - scalable and adding new pthread APIs, NPTL made Linux competitive with - Windows in the multi-threaded world. Unfortunately it also broke many - assumptions made by Wine (as well as other applications such as the - Sun JVM and RealPlayer) in the process. - </para> - - <para> - There was, however, some good news. NPTL made Linux threading powerful - enough that Win32 threads could now be implemented on top of pthreads - like any other normal application. There would no longer be problems - with mixing win32-kthreads and pthreads created by external libraries, - and no need to override glibc internals. As you can see from the - relative sizes of the <filename>loader/kthread.c</filename> and - <filename>loader/pthread.c</filename> files, the difference in code - complexity is considerable. NPTL also made several other semantic - changes to things such as signal delivery so changes were required in - many different places in Wine. - </para> - - <para> - On non-Linux systems the threading interface is typically not powerful - enough to replicate the semantics Win32 applications expect and so - kthreads with the pthread overrides are used. - </para> - </sect2> - - <sect2> <title>The Win32 thread environment</title> <para>
participants (1)
-
Alexandre Julliard