Started playing with Wineserver on mingw/cygwin again

Eric Pouech eric.pouech at wanadoo.fr
Thu Feb 6 14:54:44 CST 2003


Ulrich Weigand wrote:
> 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 ...

this is also used in the debugging API support in the kernel (which you 
can see as an extension of SuspendThread / ResumeThread)
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

> 
>>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.
I thought there were also issues where a LDT wasn't correctly inherited 
thru clone(), but I may be mistaken on that one.

A+
-- 
Eric Pouech




More information about the wine-devel mailing list