My Oracle Support Banner

RP/TUX 8.0 - win32 multithread issue when libengine is loaded after threads create (Doc ID 776758.1)

Last updated on JANUARY 19, 2018

Applies to:

Oracle Tuxedo / Tuxedo / 8.0
Information in this document applies to any platform


Tuxedo 8.0 on W2K

Reproducer on \\supportprod\attachments ( called ).

win32 multithread issue when libengine is loaded after threads create.  You will see the
application hang insteadof exiting normally.

The problem is quite easy to reproduce.
Just use the simpapp server side.
And make a native client out of ( this is a visual studio 6 project, find the *.dsw project file ). 
Compile all components and run the sample with 
testmw 3 10 
for example. First param is the number of threads, and second the calls per thread.

Analysis from BEA France:

This sample basically create threads, each loading a tuxedo wrapper lib.
The main program is not linked with the tuxedo libs.
Only the loaded lib does some thuxedo things and is linked with tuxedo.

The problem comes from the fact that Tuxedo makes some thread variables at thread creation time by the 
dllMain(DLL_THREAD_ATTACH) mechanism.  But when the libengine is loaded after the threads are created 
the dllMain (DLL_THREAD_ATTACH) is never called.

There is a fallback mechanism in _e_thread_init, but the code is different : 
it "forgets to set the thread id" and the ipcs are broken after :
_e_thread_init ( file gpcntxt.c ) 

lines :

        sprintf(name, "IPC%d.%d", MYPID, MYTID);

should be written :
        MYPID= GetCurrentProcessId();
        sprintf(name, "IPC%d.%d", MYPID, MYTID);

then this fixes the problem (I tried this)


To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.