Re: pthreads and mono
On Wed, 2003-03-12 at 04:23, Alexandre Julliard wrote: Dan Kegel [EMAIL PROTECTED] 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. -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: pthreads and mono
Not exactly; the issue is more to make sure we can override the pthreads symbols properly to do the Wine housekeeping stuff we need to do. So the symbols only have to be overridden for within Wine? Because one solution would be to have two pthread implementations linked in at once, and to keep them separate (lots of fun with the current glibc linker, but they are interested in adding features to do that). It works when building as a normal Winelib app, but this is not how the Mono guys want to use it from what I understand. At the moment they use something called monostub, which is a WineLib app. That loads and initialises through wine monostub.exe.so, then loads and hosts the Mono VM inside it. They'd prefer to just dlopen() the APIs as called via P/Invoke, but I got the impression they didn't really know how to do that... is there much special setup involved when you run wine foo.exe.so? -- Mike Hearn [EMAIL PROTECTED] QinetiQ - Malvern Technology Center
Re: pthreads and mono
Mike Hearn [EMAIL PROTECTED] writes: So the symbols only have to be overridden for within Wine? Because one solution would be to have two pthread implementations linked in at once, and to keep them separate (lots of fun with the current glibc linker, but they are interested in adding features to do that). No, the whole point is to override them outside of Wine. We don't care about the pthreads symbols in Wine, but if some other library calls say pthread_create() it needs to go through Wine so that we can initialize the Wine structures for the new thread. At the moment they use something called monostub, which is a WineLib app. That loads and initialises through wine monostub.exe.so, then loads and hosts the Mono VM inside it. They'd prefer to just dlopen() the APIs as called via P/Invoke, but I got the impression they didn't really know how to do that... is there much special setup involved when you run wine foo.exe.so? Quite a bit yes. But if they are doing this then there shouldn't be any pthreads issue, things are supposed to work in this setup (except maybe for the pthreads bits that we don't support yet but these shouldn't be hard to add). -- Alexandre Julliard [EMAIL PROTECTED]
Re: pthreads and mono
Quite a bit yes. But if they are doing this then there shouldn't be any pthreads issue, things are supposed to work in this setup (except maybe for the pthreads bits that we don't support yet but these shouldn't be hard to add). Is that setup modular at all? As in, could you start a program as a normal app, then dlopen some shlibs and call wineLibInit() for instance then link against windows DLLs as needed? The monostub approach is fine for now, but obviously being able to load Wine on demand is a cleaner approach.
Re: pthreads and mono
On 10 Mar 2003, Alexandre Julliard wrote: [...] Not exactly; the issue is more to make sure we can override the pthreads symbols properly to do the Wine housekeeping stuff we need to do. It works when building as a normal Winelib app, but this is not how the Mono guys want to use it from what I understand. Could we solve this problem by moving the pthread stuff to a libwine_pthread.so library. Then one could set LD_PRELOAD=libwine_pthread.so to have Wine's pthread implementation. Would that make it possible to use Wine stuff from a regular application? Wine itself could simply link to that library in the right place a do away with the LD_PRELOAD bit. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ We are Pentium of Borg. You will be approximated. Division is futile.
Re: pthreads and mono
Francois Gouget [EMAIL PROTECTED] writes: Could we solve this problem by moving the pthread stuff to a libwine_pthread.so library. Then one could set LD_PRELOAD=libwine_pthread.so to have Wine's pthread implementation. Would that make it possible to use Wine stuff from a regular application? No, because the Wine pthreads routines use ntdll, and so they need the Wine environment to be initialized properly. -- Alexandre Julliard [EMAIL PROTECTED]
Re: pthreads and mono
Mike Hearn [EMAIL PROTECTED] writes: Is that setup modular at all? As in, could you start a program as a normal app, then dlopen some shlibs and call wineLibInit() for instance then link against windows DLLs as needed? No, that's not supported at the moment, and it's a bit tricky to implement. It may happen someday but it's not really a priority right now. -- Alexandre Julliard [EMAIL PROTECTED]
Re: pthreads and mono
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. This may be what needs to happen in the long run. Can you point to a document that explains the issues such an effort would face? Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: pthreads and mono
On March 11, 2003 08:19 pm, Alexandre Julliard wrote: No, because the Wine pthreads routines use ntdll, and so they need the Wine environment to be initialized properly. True, but would it be possible somehow to do some late binding to the NTDLL stuff (using dlopen)? We get to override the symbol, and then we have fighting chance of doing something decent with it :) -- Dimi.
Re: pthreads and mono
Dan Kegel [EMAIL PROTECTED] 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. -- Alexandre Julliard [EMAIL PROTECTED]
Re: pthreads and mono
Mike Hearn [EMAIL PROTECTED] writes: I'd just like to double check - will Alexandres new threading work allow Wine to be linked into a program that uses pthreads ok? In particular, the Mono guys are wondering... they were thinking of shipping a modified libwine and all kinds of things that sound bad, so it'd be good to know whether the NPTL implemention sorts this out No, it won't make much difference. We are currently providing pthreads wrappers in Wine, and we'll need to do basically the same thing for NPTL. So if the current wrappers don't work for Mono the new ones probably won't do much better; we need to find a proper fix for that problem regardless of the underlying thread implementation. -- Alexandre Julliard [EMAIL PROTECTED]
Re: pthreads and mono
No, it won't make much difference. We are currently providing pthreads wrappers in Wine, and we'll need to do basically the same thing for NPTL. So if the current wrappers don't work for Mono the new ones probably won't do much better; we need to find a proper fix for that problem regardless of the underlying thread implementation. But what is the fix? IIRC the basic problem was the Wine internal pthreads implementation conflicting with the one linked in via libmono and libgc, something like that. Is this the ELF symbols have global scope problem come to bite us on the ass yet again, or does it go deeper than that?
Re: pthreads and mono
Mike Hearn [EMAIL PROTECTED] writes: But what is the fix? IIRC the basic problem was the Wine internal pthreads implementation conflicting with the one linked in via libmono and libgc, something like that. Is this the ELF symbols have global scope problem come to bite us on the ass yet again, or does it go deeper than that? Not exactly; the issue is more to make sure we can override the pthreads symbols properly to do the Wine housekeeping stuff we need to do. It works when building as a normal Winelib app, but this is not how the Mono guys want to use it from what I understand. -- Alexandre Julliard [EMAIL PROTECTED]
