Alexandre Julliard wrote:
> The other solution is to try to use the existing libpthread to create
> our threads; if we can work around the %gs register problem, this
> would have the advantage of better integrating with the native
> libraries (for instance gdb would then be able to understand what's
> going on with threads). This is IMO a more elegant solution, but the
> big question is: can it be made to work?
It's been a while since I thought about that, but I seem to recall two
main problems:
- libpthread sets up its own segments and stores selectors to them in %gs
- libpthread uses the current stack pointer to determine the current thread
Actually, I'm not sure whether any version of libpthread uses *both* of
those constructs at the same time (as both are used to determine the
current thread), but I've seen (different) versions that use either one.
The problem with the first method is, first, that Wine thinks it is the
only one modifying the current LDT, and doesn't even check whether a
selector is really unused if it thinks it is. This leads to descriptors
created by libpthread being overwritten by Wine descriptors. This problem
could probably be fixed; however, there might be race conditions involved ...
The second problem is that libpthread relies on %gs remaining unchanged. For
Wine, this would mean that we'd have to save %gs during 16-bit calls (and
restore it in signal handlers if necessary). This would be easy to do. But,
even 32-bit code might conceivably modify %gs under Windows; this would
be problematical ...
The problem with the second method is that we would be forced to use the
stack created by pthread_create for the new thread, and couldn't use the
stack created by Wine. This means that the TEB stack limits would need
to be adapted (easy), and that all thread stacks must be of the same size,
no matter what size the Windows app requests. Depending on the app, of
course, that latter requirement might be impossible to fulfil ...
Unless there are further problems that I'm not aware of, this would mean
that while it might be possible to run some Win32 apps using pthreads,
there could be apps for which it is impossible.
One possible solution to remove the restrictions on Win32 apps would be
to treat Win32 apps the same way as Win16 apps, using explicit transition
thunks. That way, we could switch from the pthreads stack to the Wine
stack, and could save/restore %gs as well ... Furthermore, this approach
would also allow to use compilers that don't support stdcall, and it might
simplify a processor emulator version of Wine. On the other hand, there's
quite a bit of overhead on every transition :-/
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
