Using pthread_create within Wine

[Phil Lodwick]

Greetings,

I have a proprietary library that has both Windows and Linux ports.  The
Windows DLL has problems running on Wine, so I have created a builtin version
of this DLL in Wine.  This has worked fine, except for one function that
basically creates a new thread and fires back events to the calling Window
application.  I believe I have traced this down to the Linux version of the
library creating the new thread with pthread_create.

Windows.exe

Call_dll_to_spawn_thread_and_register_callback(MyCallbackfunc);

Windows DLL implemented in wine:

void * NewThread(void *p)

{

MyParams *params = (MyParams *)p;

for (i = 0; i < 500000; i++)

p->Callback();

}

void Call_dll_to_spawn_thread_and_register_callback(void
(*callback)())

{

MyParams *params = (MyParams
*)malloc(sizeof(MyParams));

params->Callback = callback;

pthread_create(&MyThread, NULL, NewThread,
(void *)params);

}

If instead of using pthread_create I use CreateThread, I never have a
problem.   I notice no other wine DLLs are using pthread_create and I have
seen hints that this might not work.  If so, how do I use the Linux library.
(Call_dll_to_spawn_thread_and_register_callback is just simulating what the
Linux library would do)

Do I create a separate thread using CreateThread to communicate back to the
Window application, so that Call_dll_to_spawn_thread_and_register_callback
effectively creates two threads, one using CreateThread (Wine DLL), one using
pthread_create (Linux Library) and then do synchronization between the two?

Any help, suggestion, ideas, questions would be greatly appreciated.

Phil

[Stefan Dösinger]

Hi,
> If instead of using pthread_create I use CreateThread, I never have a
> problem.   I notice no other wine DLLs are using pthread_create and I have
> seen hints that this might not work.  If so, how do I use the Linux
> library. (Call_dll_to_spawn_thread_and_register_callback is just simulating
> what the Linux library would do)

There are some problems if Linux libraries create a thread behind the calling 
application in Wine. I do not know what the problem is precicely, but I think 
Win32 code can be confused if it is called from a thread that doesn't have 
the Win32 thread structures that should belong to it. If the library creates 
a thread, and this thread calls back into the Windows app's code, the code 
running in the windows application can't find the current thread ID, simply 
because the Win32 thread information is not there.

There was a problem like this with the CoreAudio library on macos, but I am 
not sure about the details.

Is there any reason why you cannot use CreateThread?

[Phil Lodwick]

> There was a problem like this with the CoreAudio library on macos, but I am
> not sure about the details.
> Is there any reason why you cannot use CreateThread?

I can't use CreateThread because the pthread_create is in a Linux library I
am calling.

My initial test of creating two threads, one that is Win32-aware and then
synchronizing between the two of them appears to work.  Does anybody know why
this might be a bad idea?

Phil

[Alexandre Julliard]

"Phil Lodwick"  writes:
> My initial test of creating two threads, one that is Win32-aware and then
> synchronizing between the two of them appears to work.  Does anybody know why
> this might be a bad idea?

It's not a bad idea, except maybe for performance reasons. As long as
you don't make Win32 calls from the pthread-created thread things
should work fine.

A better way would be to override pthread_create to create a proper
Win32 thread; we already do that for kthreads support so it shouldn't
be too hard to do the same thing for pthreads.

[Alex Villací­s Lasso]

Phil Lodwick escribió:
> Greetings,
>
> I have a proprietary library that has both Windows and Linux ports.  The
> Windows DLL has problems running on Wine, so I have created a builtin version
> of this DLL in Wine.  This has worked fine, except for one function that
> basically creates a new thread and fires back events to the calling Window
> application.  I believe I have traced this down to the Linux version of the
> library creating the new thread with pthread_create.

Could you please elaborate on what kind of problems you have when trying 
to use the Windows version of your library under Wine? Is there any 
particular reason you do not want to build a pure Linux application that 
links in the Linux library, therefore bypassing Wine entirely?

Your explanation sounds as if you do not have access to the source code 
of the library, and you are therefore trying to use libraryfile.a to 
link into a Wine .so file. Is this correct? If so, is the Windows 
version of the library a .lib file, or a .dll file? Am I right to guess 
your Linux version of the library resides in a .a file, not a .so file ?

If your library is really a .lib file, then what happens if you build 
(under Windows) a .dll file which links in your .lib file, and then 
build a test program that exercises the newly created .dll file? Does it 
work correctly in Windows? Just to check, your library might not support 
being loaded as dynamic code.

[Phil Lodwick]

> Could you please elaborate on what kind of problems you have when trying 
> to use the Windows version of your library under Wine?

The Wine socket implementation has problems when it comes to select.  A fix
for this problem is not currently on anybody's radar.
http://www.winehq.org/pipermail/wine-devel/2006-February/044588.html
> Is there any particular reason you do not want to build a pure 
> Linux application that links in the Linux library, therefore 
> bypassing Wine entirely?

The application uses libraries that are only available on Windows.
> Your explanation sounds as if you do not have access to the source code 
> of the library, and you are therefore trying to use libraryfile.a to 
> link into a Wine .so file. Is this correct? If so, is the Windows 
> version of the library a .lib file, or a .dll file? Am I right to guess 
> your Linux version of the library resides in a .a file, not a .so file ?

No, the Linux version is a .so.

However, now that I have two threads with synchronization between them, all
seems good:

EXE <--> Wine DLL (Win32-aware thread)
    		^
    		|
    		| Synchronization between threads.
    		|
    		v
    Wine DLL <--> Linux .so (pthread_create thread)

Phil