Dan Kegel dank@kegel.com writes:
I wonder if it's time to consider what it would take to truly and completely integrate winethreads and glibc threads, to allow unfettered use of linux shared libraries from winelib programs.
That's basically what the pthreads routines in Wine are for, they provide wrappers so that pthreads calls in linux shared libraries do the right thing. We'll probably need a somewhat different implementation for the NPTL version but the idea is the same. Not every pthreads function is implemented at the moment but it wouldn't be a big deal to add the missing ones.
On Wed, 2003-03-12 at 04:23, Alexandre Julliard wrote:
Dan Kegel dank@kegel.com writes:
I wonder if it's time to consider what it would take to truly and completely integrate winethreads and glibc threads, to allow unfettered use of linux shared libraries from winelib programs.
That's basically what the pthreads routines in Wine are for, they provide wrappers so that pthreads calls in linux shared libraries do the right thing. We'll probably need a somewhat different implementation for the NPTL version but the idea is the same. Not every pthreads function is implemented at the moment but it wouldn't be a big deal to add the missing ones.
I think one solution for third party libs for now is to use dlsym() to bind to the pthreads symbols... that way if it's being run from outside Wine, the call will fail and it knows to dlopen libpthreads first before continuing, and if Wine is already linked in then dlsym() will pull them from the global symbol table and the housekeeping gets done. It takes a bit of extra effort, and obviously you need to patch the libraries, but it's nothing terrible.