On Fri, 24 Mar 2000, Jeremy White wrote:
> To rehash what is already known:
>
> After a scan of the glibc 2.1 source code (and no experimental evidence
> whatsoever), I found only the following two problems:
>
> 1. malloc and free will fail badly
>
> I see two issues. First, the code for malloc tests to see if
>__pthread_initialize is
> available. If so, it invokes it. I believe that __pthread_initialize will
> actually run correctly, and start the pthread_manager. I have no proof of
>this.
> Second, as malloc and free manipulate internal structures, they
> rely on macros from malloc-t.h. The ones I inspected were
> mutex_init, mutex_lock, et. all. Basically, if libpthread is linked in,
> and the weak symbols for __pthread_mutex_xxx are available,
> then malloc will use them, otherwise they turn into NOPs
> (and malloc is presumably running in a single thread environment).
>
> However, in our case, the code for pthread_mutex_lock will be invoked.
> That code, in turn, grabs the pthread_self descriptor from the GS
> register. Of course, we're not really a pthread and *boom* down she
> goes.
>
> 2. errno will fail
> Again, same basic issue.
My original pthread patch defined only the __pthread_xxx routines that
glibc used, so that libc would use them instead of assuming a
single-thread environment, since wine IS multithreaded.
pthread was normally never linked in before XFree86 4.0 appeared, so when
it did, I had to update the patch to also define standard pthread symbols
to override pthread's own (libwine is before pthread-using X11 libs on the
link command line...)
> However, I found no further instances where glibc examines the weak
> aliasing on the pthread functions. Of course, I did not look at the
> source code for X 4.0 or any other library to see in what ways it
> depends on the weak aliasing of pthreads.
They do not, the OpenGL and MT parts of XFree86 4.0 uses pthreads
directly, without going through any weak aliases. In other words, they
explicitly link it in.
> As I understand Ove's pthread patch, his patch resolves this problem.
> I don't have his patch in front of me, but I believe he did this by
> registering Wine threads with libpthread (setting up the GS register),
> and by correspondingly trapping the creation of threads from
> libpthread and registering them with Wine.
No, if I did that we could as well use pthreads directly, but messing with
GS is incompatible with Win32 threading, which is one reason why we don't.
I just implement the pthread primitives on top of Win32 synchronization
primitives. For example, pthread_mutex_init() is a wrapper for
InitializeCriticalSection(), pthread_mutex_lock() is a wrapper for
EnterCriticalSection(), etc...
> So, my basic question is:
> What is wrong with Ove's patch, and why can't it be part of the
> main Wine release?
That is explained at the beginning of the patch - it is currently quite
glibc-specific (Alexandre calls in unportable, although I wouldn't myself
consider it impossible to port to other systems, like FreeBSD), and
Alexandre really wants to see a portable fix for libc threadsafety before
slipping in system-specific workarounds that ~90% of the developers would
consider "good enough" (and the rest wouldn't know how to fix).
> Further, what work do we need to do in order
> to resolve this problem for the Wine mainstream? Do we need
> changes to glibc? It seems like the problem areas are small enough
> in scope (malloc and errno) that we ought to be able to create
> a lasting solution.
The XFree86 4.0 problems are not related to glibc, glibc is completely
innocent (for a change). I can't think of any good solutions myself.
