Hi,
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
thanks -mike
Mike Hearn m.hearn@signal.qinetiq.com 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.
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?
Mike Hearn mike@theoretic.com 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.
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 m.hearn@signal.qinetiq.com 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).
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.
Mike Hearn mike@theoretic.com 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.
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 fgouget@free.fr 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.
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 :)
-
Alexandre Julliard -
Dimitrie O. Paun -
Francois Gouget -
Mike Hearn -
Mike Hearn