Ulrich Weigand <[EMAIL PROTECTED]> writes:
> 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 ...
libpthread is apparently allocating the selectors sequentially, so we
could avoid touching the first n selectors, where n is the max number
of threads we will create.
> 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 ...
It shouldn't be too much of a problem since we wouldn't use pthreads
functions except for thread creation; so basically we would need to
restore %gs only when calling libc functions that might use pthreads
routines, and in signal handlers.
> 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 ...
It seems that you can specify the stack size and location with thread
attributes and still have it locate the current thread correctly.
--
Alexandre Julliard
[EMAIL PROTECTED]
