NTPL & pthreads locks

[Peter Hunnisett]

Gavriel State wrote:

> Dan Kegel wrote:
>
>> Alexandre Julliard wrote:
>>
>>> I don't think we can implement Win32 primitives on top of pthreads, at
>>> least not in a reasonable way. We may be able to do it on top of the
>>> raw kernel futexes, but that's not exactly libc integration (and it
>>> will most likely require new kernel features too). And the only reason
>>> for doing that would be performance, it's certainly not going to make
>>> things more intuitive or more solid.
>>
>>
>>
>> Somebody begs to differ.  From
>> http://downloads.transgaming.com/files/winex-3_0_releasenotes.txt :
>>
>>    * The core threading model has moved to pthreads to decouple WineX 
>> from
>>      the continuing changes to certain core system libraries.
>>
>> If Gav can do it, why can't we? :-)
>> - Dan
>
>
> We did not implement Win32 primitives on top of pthreads in WineX 3.0.
> We simply extended our previous pthreads work to support glibc 2.3.2 and
> NPTL, just as Alexandre was forced to for Wine.  I still believe that
> for performance, ShmServer is the most direct way to go to improve
> Win32 primitives for now.  I have yet to see any good arguments as to
> why it should not at least be a user-selectable option.
>
> Our pthreads code will be making it into ReWind once we've had some
> time to catch our breaths.  Currently it's not even in WineX SF CVS due
> to intermingling with our copy protection code.
>
> According to Peter Hunnisett, there may be a few things that our new
> pthreads code catches that Alexandre's similar code does not, but
> I'm not the expert on this.  Peter, perhaps you can fill Alexandre
> in on the high level details, pending the patch going into ReWind. 

The big thing that I noticed in the couple of seconds that I glanced 
that the nptl patch was the signal handling was not correct for pthreads.

For instance pthread_sigmask should be used instead of sigprocmask and 
wine should not be resetting signal handlers willy nilly as they're 
shared across all threads. SIGNAL_Reset (or whatever it is) should not 
tear down the signal handlers when 1 thread exits as they're still used 
by other threads.

Also, since the patch was not designed to support LinuxThreads and its 
ilk, wine doesn't handle the case where it gets signals that are not for 
wine threads (ie the %fs is not valid).

Also, I think that the tkill stuff that went in is only being used in 
the wineserver. I'm not sure if wine had any places where it should have 
been used; WineX did.

As indicated by Gav, we'll be submitting our stuff to ReWind so you can 
poke at it more there.

Regards,
Peter



>
>
> Take care,
>  -Gav
>