Thanks, Mike and Lionel.
"Mike Hearn" mike@theoretic.com wrote:
Right. Really, you *want* aceutilities.so to use the Wine versions. In theory, it should all work fine except the threads that aceutilities creates are "wine-aware". If it doesn't, that means the Wine pthreads emulation is not perfect yet.
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.
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. Since non-x86 platforms seem to use the native pthread library, 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.
Our application is just using winelib; there are no emulated dlls or exes. In addition, if it helps, only the main thread of our program calls any winelib functions. Actually, right now the helper threads to call PostMessage() to request the main thread to do some work, but I think we could replace the PostMessage() calls with a socket or some other mechanism. 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.
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.
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.
Thanks,
Eric Frias efrias@syncad.com