Ulrich Weigand wrote:
this is also used in the debugging API support in the kernel (which you can see as an extension of SuspendThread / ResumeThread)Eric Pouech wrote:among the things we have to take care of:
- signals: signal, in current implementation, is sent to a thread. in nptl, it's sent to the process. So, lots of thread control has to be rewritten
- in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port)
I think this is mostly used to implement SuspendThread / ResumeThread, which cannot be portably implemented using the pthreads interface. I do not know how to solve this issue without relying on implementation
details ...
I don't see any way to actually stop a pthread (unless changing its scheduling policy&priority, but rather ugly)
(pthread_suspend seems to have been implemented in some pt libs, but isn't in the opengroup specs standard AFAICS)
which may be quite an issue
I thought there were also issues where a LDT wasn't correctly inherited thru clone(), but I may be mistaken on that one.from what I've seen, the LDT/GDT with nptl should be easier:
- for Win32 processes, as Ulrich already wrote, we could got rid of LDT (and only rely on GDT) for %fs and TEB allocation
- for Win16 processes, we would still require LDT sharing across pthreads, which I don't how it's handled right now
LDT sharing should not be a problem (there were bugs in kernels 2.0.x
w.r.t. that issue, but those are long since fixed). The core problem with the LDT was that the LinuxThreads implementation used to allocate
entries with modify_ldt, and Wine would do the same, without any coordination between the two. This is no longer a problem as the new
ntpl thread library does not use the LDT at all anymore.
A+
--
Eric Pouech
