Help with WINE and POSIX threading

Marcus Meissner marcus at jet.franken.de
Thu Oct 27 07:19:02 CDT 2005


On Wed, Oct 26, 2005 at 11:01:51AM -0700, ssawai wrote:
> 
> Message body follows:
> 
> Marcus,
> 
> We have been using WINE for about a year to port the 
> Windows version of our product to Red Hat AS 3.0. We have 
> come up against some issues with threading and our 
> developers have some questions which I am including below.

Please ask them on wine-devel at winehq.org ... I am just one of
the developers ;) I am cc'ing the list.

> 1) Wine version
> 
> According to winehq.org, Wine is still alpha software. Since 
> we are not
> interested in Wine as a complete Windows simulator and we 
> don't plan to
> run binaries compiled on Windows, what would be the best 
> (development)
> Wine version to use?

2 days ago we released version 0.9, our first BETA version.

This is the version to use for now ;)


> 2) Threading
> 
> On several places we use third-party components that use native pthreads
> from which we receive callbacks in different pthreads.
> 
> Is it possible to use Wine/pthread mix? What would be the preferred way
> of doing things?

Umm. I do not know. It might be possible.

We provide a kind of barebones pthread implementation ourselves
to help this mix.

> Our tests show that Wine implements Win32 threads by creating new
> processes (via clone() syscall). This is a problem, because, pthreads
> spawned from Wine thread, cannot be interlocked with Wine/Win32 Mutex or
> CriticalSection. They also seem to be scheduled (by kernel) only within
> parent Wine thread. If parent Wine thread terminates early - we have a
> crash the moment when one of the orphan pthreads try to place a
> callback.


> 3) Dynamic library loading
> 
> On many places we use dynamic library loading (LoadLibrary() on Win32).
> Possibly we will need to load native libraries also. Is it possible to
> load shared libraries (.so) linked with Wine, with native dlopen(),
> since we don't need the Win32 DllMain mechanism. What would be the
> preferred/best way of doing things?

dlopen() is possible from within a WINE context.

dlopen() a wine library from a non-WINE program will currently not work,
you have to setup the wine context before.

> Can you help with these? If not, can you suggest who may 
> be able to give us some expert insight with our issues?

I hope some of the other developers on wine-devel at winehq.org can
fill in here.

Ciao, Marcus



More information about the wine-devel mailing list