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 -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
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. Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. gav(a)transgaming.com http://www.transgaming.com/ Let the games begin
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
Peter Hunnisett <peter(a)transgaming.com> writes:
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.
We don't call SIGNAL_Reset for NPTL. And using pthread_sigmask shouldn't make any difference, sigprocmask is thread-local anyway (and it avoids a few #ifdefs...) -- Alexandre Julliard julliard(a)winehq.com
Alexandre Julliard wrote:
Peter Hunnisett <peter(a)transgaming.com> writes:
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.
We don't call SIGNAL_Reset for NPTL. And using pthread_sigmask shouldn't make any difference, sigprocmask is thread-local anyway (and it avoids a few #ifdefs...)
sigprocmask may be thread-local in NPTL, but it's not in SUSv3, which doesn't at all specify what happens when you call sigprocmask in a multithreaded program. See http://www.opengroup.org/onlinepubs/007904975/toc.htm For portability's sake, one should probably use pthread_sigmask. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Dan Kegel <dank(a)kegel.com> writes:
sigprocmask may be thread-local in NPTL, but it's not in SUSv3, which doesn't at all specify what happens when you call sigprocmask in a multithreaded program. See http://www.opengroup.org/onlinepubs/007904975/toc.htm For portability's sake, one should probably use pthread_sigmask.
If we really wanted portable threading we should use only pthreads functions throughout. But of course there's the small drawback that it wouldn't let us run most Windows apps... -- Alexandre Julliard julliard(a)winehq.com
participants (4)
-
Alexandre Julliard -
Dan Kegel -
Gavriel State -
Peter Hunnisett