Alexandre,
If I understand correctly, we currently implement the pthreads locks on top on Wine locks because the standard pthreads locks are not powerful enough to support all Win32 locking primitives. Integrating these locks is necessary for integrating Wine with the pthreads Universe.
Now, given the new NTPL work, would it be possible/feasible/desirable to implement the Win32 locks on top of NTPL primitives (such as futexes)?
At the very least it makes the setup a lot more intuitive, and less likely to break. If we are to follow this path, there are portability problems. But do we support this sort of libc integration of Solaris and *BSD? And it seems to me that it shouldn't be too hard for these systems to provide something that would allow us to implement all Win32 locking primitives, and the end result would be a lot less brittle.
It's not just portability to other forms of unix, it's portability to older versions of glibc as well - some Wine users are using for instance Xandros which is based on pretty old components now, any reimplementation of Wine threading would have to take that into account.
On Tue, 2003-04-08 at 07:11, Dimitrie O. Paun wrote:
Alexandre,
If I understand correctly, we currently implement the pthreads locks on top on Wine locks because the standard pthreads locks are not powerful enough to support all Win32 locking primitives. Integrating these locks is necessary for integrating Wine with the pthreads Universe.
Now, given the new NTPL work, would it be possible/feasible/desirable to implement the Win32 locks on top of NTPL primitives (such as futexes)?
At the very least it makes the setup a lot more intuitive, and less likely to break. If we are to follow this path, there are portability problems. But do we support this sort of libc integration of Solaris and *BSD? And it seems to me that it shouldn't be too hard for these systems to provide something that would allow us to implement all Win32 locking primitives, and the end result would be a lot less brittle.
On April 8, 2003 08:37 am, Mike Hearn wrote:
It's not just portability to other forms of unix, it's portability to older versions of glibc as well - some Wine users are using for instance Xandros which is based on pretty old components now, any reimplementation of Wine threading would have to take that into account.
Well, I'm not suggesting we drop support for glibc 2.[012].x systems. First question is 'Is it possible'? If it is, would we want it? What are the advantages/disadvantages? Only then can we ask 'Can we do it in a clean way, without dropping support for the old glibc?'. Can we do it at runtime or must it be a configure-time thing? And so on...
"Dimitrie O. Paun" dpaun@rogers.com writes:
At the very least it makes the setup a lot more intuitive, and less likely to break. If we are to follow this path, there are portability problems. But do we support this sort of libc integration of Solaris and *BSD? And it seems to me that it shouldn't be too hard for these systems to provide something that would allow us to implement all Win32 locking primitives, and the end result would be a lot less brittle.
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.
-
Alexandre Julliard -
Dimitrie O. Paun -
Mike Hearn