This seems to be the case, otherwise we would have never noticed the pthread emulation. We didn't really dig into what the problem was yet though.
It might be worth doing that.
Is any of the pthread emulation necessary if we're only using winelib, not the native emulation? I read some things that made it sound like one of the big problems was native windows code using one of the registers that pthreads reserves.
Well threading is kind of hairy. My understanding of the problem (though I'm in no way a Wine guru) is that the Win32 threading model has primitives that can't be mapped onto pthreads, so rather than try and do that (and fail) Wine does its own threading and then maps pthreads to Win32/Wine threads for Linux-native code that wishes to use it. So, I don't think it makes much difference whether you use native DLLs or not - code written to Win32 may make use of threading abilities that pthreads just doesn't have.
Since non-x86 platforms seem to use the native pthread library,
Yeah, I've heard something like this as well. IIRC it was part of the work done to get Wine going on PPC..... not sure though.
maybe we could coax our copy of winelib into using native pthreads also, but imposing the restriction that we can't link to windows-native dlls.
Perhaps. I think it's more a restriction on what the APIs can do though.
In addition, if it helps, only the main thread of our program calls any winelib functions.
Yes, I think that might help. Only threads that use Win32 need to use the Wine pthread mapping as far as I'm aware (but again, could be wrong).
Our program doesn't create any windows threads via CreateThread(), So, if we promised not to call any winelib code from any thread that wine doesn't know about, would that take us out of harm's way? If that's the case, we could probably link ACE to a static version of the pthread library, and everything would just work.
Try it :) But try to find out why the Wine pthreads mapping doesn't work first.
If we could have both versions of the pthread library co-existing in the same process, we were also thinking that we might be able to rename the wine versions of the pthread functions to something like wine_pthread_create(), and then do "#define pthread_create wine_pthread_create", but it sounds like this would break other programs.
It might well do.... if WineLib (win32) code interacts with threads that Wine doesn't know about things would probably break.
I've read that the MONO folks have figured out how to get threading working, but it sounds like their solution was very complicated (although I haven't tried to really understand what they did), and I'd like to avoid that if we possibly can.
The Mono team produced an enormous patch that basically commented out anything that got in their way :) It produced a separate set of binaries. I don't really grok how they did it, but this issue has been discussed on wine-devel many times now. Basically Wine has to control elements of the process state for various reasons, which is why WineLib apps aren't just ./foo, they are `wine foo.exe.so`. The Mono patches allowed it to be dlopened().
thanks -mike