On Sun, 26 Mar 2000, Ulrich Weigand wrote:
> So, it would appear that if we
>
> - use pthread_attr_setstack... to point pthread to the Wine stacks
> - increase FIRST_LDT_ENTRY_TO_ALLOC to something like PTHREAD_THREADS_MAX
> - save/restore %gs across 16-bit code and in signal handlers
>
> (all of which should be easy to do), we should be able to run all apps
> that don't modify %gs (which I assume to be most apps ...) under pthreads.
> At least, I guess it's worth a try ...
>
I have been holding out on you. :( I have a patch that runs wine on
pthreads in glibc 2.1, that works for 32-bit programs at least. I didn't
bother with the LDT or %gs stuff since linuxthreads-0.8 does not use it,
due to bugs in the 2.0 kernels. (So it may come back some day.)
(If %gs ever comes back, maybe we can convince Drepper to put hooks into
linuxthreads for us to use. They have a function called thread_self that
returns a pointer to their thread data structure. We could replace that
function and just keep their data in our TEB somewhere.)
My current biggest concern is that the signal stack handling is
problematic. When handling a SIGSEGV, and do the SEH unwind thing, do we
ever return from the signal handler, or do we just effectively longjmp
back to the right location?
My mail setup is currently uh non-optimal, so I'll have to send the patch
in a separate post.
BTW, I have not tried this with XF4.
Andrew Lewycky
[EMAIL PROTECTED]
