couple of questions about pthreads (scheduler/pthread.c) inwine

[Mike Hearn]

> 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