After last night's changes to loader/pthread.c,v
revision 1.2 date: 2003/11/09 01:25:23; author: julliard; state: Exp; lines: +67 -11 Moved the remaining SYSDEPS_* functions to the wine_pthread interface. Let the pthread library allocate the stack itself.
we have a new portability problem, namely
wine/loader/pthread.c:97: undefined reference to `pthread_getattr_np'
Given that loader/pthread.c is about POSIX threads, is it really correct/good to use a non-POSIX function?
Gerald
PS: On FreeBSD, pthread_getattr_np does not exist, but there is a function pthread_attr_get_np which seems to be equivalent. On Solaris, neither seems to exist.
Alexandre,
I noticed that you disabled using pthreads on non-Linux platforms by means of the following patch:
revision 1.12 of loader/Makefile.in date: 2003/11/11 00:48:21; author: julliard; state: Exp; lines: +12 -11 Only build both Wine binaries on Linux, pthread support doesn't work on other platforms.
Would you mind reverting this, at least for FreeBSD? FreeBSD does have POSIX threads, in -STABLE and especially improved in -CURRENT (which will soon become the stream for regular releases.
Plus, the following really looks like a problem to me (for portability on Linux as well). If you want to keep it like that nevertheless, I volunteer to submit a small and clean patch to provide the workaround on FreeBSD once you re-enabled POSIX threads there.
On Sun, 9 Nov 2003, Gerald Pfeifer wrote:
After last night's changes to loader/pthread.c,v we have a new portability problem, namely
wine/loader/pthread.c:97: undefined reference to `pthread_getattr_np'
Given that loader/pthread.c is about POSIX threads, is it really correct/good to use a non-POSIX function?
PS: On FreeBSD, pthread_getattr_np does not exist, but there is a function pthread_attr_get_np which seems to be equivalent. On Solaris, neither seems to exist.
Thanks for your considerations; your support for portability and non-Linux platforms is really appreciated!
Gerald
On Sat, 15 Nov 2003, Gerald Pfeifer wrote:
Alexandre,
I noticed that you disabled using pthreads on non-Linux platforms by means of the following patch:
revision 1.12 of loader/Makefile.in date: 2003/11/11 00:48:21; author: julliard; state: Exp; lines: +12 -11 Only build both Wine binaries on Linux, pthread support doesn't work on other platforms.
Would you mind reverting this, at least for FreeBSD? FreeBSD does have POSIX threads, in -STABLE and especially improved in -CURRENT (which will soon become the stream for regular releases.
My understanding is that Posix threads have never been and will never be sufficient for Wine. The only reason we have a pthreads version of Wine is that on recent Linux distributions the way they are implemented makes it possible for Wine to achieve its means without using undocumented interfaces (i.e. without overriding obscure internal glibc functions). But that's not the same as saying Wine is only using the standard pthreads API either.
And this is why wine-pthread won't work on other platforms that have pthreads, and why Alexandre disabled compiling wine-pthread on non-Linux platforms.
That's my undrstanding of the matter anyway. Alexandre will correct me if I'm wrong.
Gerald Pfeifer gerald@pfeifer.com writes:
Would you mind reverting this, at least for FreeBSD? FreeBSD does have POSIX threads, in -STABLE and especially improved in -CURRENT (which will soon become the stream for regular releases.
Posix threads are not enough, we need an implementation that works the way NPTL works on Linux, based on kernel threads, and with kernel support for signals, thread register, ptrace, etc. Last I checked FreeBSD was a user-mode implementation, which cannot possibly be made to work. If this has changed and FreeBSD uses kernel threads now, they could maybe be used depending on how they are implemented, but this will require a lot more work that simply linking against libpthread. This will have to be done by someone who understands the FreeBSD pthreads implementation in detail; and until this is done there is no point in enabling wine-pthread on FreeBSD.
On Sat, 15 Nov 2003, Francois Gouget wrote:
My understanding is that Posix threads have never been and will never be sufficient for Wine. The only reason we have a pthreads version of Wine is that on recent Linux distributions the way they are implemented makes it possible for Wine to achieve its means without using undocumented interfaces (i.e. without overriding obscure internal glibc functions). But that's not the same as saying Wine is only using the standard pthreads API either.
On Sat, 15 Nov 2003, Alexandre Julliard wrote:
Posix threads are not enough, we need an implementation that works the way NPTL works on Linux, based on kernel threads, and with kernel support for signals, thread register, ptrace, etc.
Thanks a lot for the detailed clarifications! Now I understand some things quite a bit better. :)
Last I checked FreeBSD was a user-mode implementation, which cannot possibly be made to work. If this has changed and FreeBSD uses kernel threads now, they could maybe be used depending on how they are implemented, but this will require a lot more work that simply linking against libpthread.
Current versions of FreeBSD also support kernel threads (in various variants), but I agree that it'll take a volunteer who is expert in that area to make it work properly.
Gerald
-
Alexandre Julliard -
Francois Gouget -
Gerald Pfeifer