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 VapMw2.zip ). Problem: 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 VapMw2.zip ( 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 : in _e_thread_init ( file gpcntxt.c ) lines : MYPROC=0; MYPID=_e_id_getpid(_TCARG); MYTID=0; sprintf(name, "IPC%d.%d", MYPID, MYTID); should be written : MYPROC=0; MYPID= GetCurrentProcessId(); MYTID=GetCurrentThreadId(); 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