CLIPS does not explicitly allocate any threads itself. Any threads
Andy wrote:
> We have integrated v6.24 of CLIPS into our C++ based application.
> Using process explorer (Process Explorer, process 'Properties' dialog,
> 'Threads' tab, 'Stack' button...) on windows, we see that there is
> normally 7 threads tied to our application server process. Once we
> initialize the CLIPS environment and evaluate a rule through CLIPS
> api's, we see that there are an additional 11 threads tied to our
> application server process. Are these additional threads from the
> CLIPS rules engine? This was identified in windows, but will they
> also show up in our unix environments?
> I have included the output from the process explorer showing the stack
> contents of the threads:
> <our application server>.exe: (1)
> ntkrnlpa.exe+0x6e9ab
> ntkrnlpa.exe+0x2bf82
> ntkrnlpa.exe+0x2c864
> ntkrnlpa.exe+0xe975c
> ntkrnlpa.exe+0x6a62c
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> ACE.dll!ACE_OS::thr_join+0x24
> MSVCR80.dll: (6) (5 ACE threads, and the windows-specific error
> handler thread)
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> ACE.dll!ACE_OS::sema_wait+0xf
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> MSWSOCK.dll+0x5fa7
> WS2_32.dll!select+0xa7
> ACE.dll!ACE_OS::select+0x2c
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> ACE.dll!ACE_OS::sema_wait+0xf
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> MSWSOCK.dll+0x5fa7
> WS2_32.dll!select+0xa7
> ACE.dll!ACE_OS::select+0x2c
> ntkrnlpa.exe+0x6e9ab
> ntkrnlpa.exe+0x2bf82
> ntkrnlpa.exe+0x2c864
> ntkrnlpa.exe+0xa89fa
> ntkrnlpa.exe+0xa97f7
> ntkrnlpa.exe+0xa22a8
> ntkrnlpa.exe+0x6a62c
> ntdll.dll!KiFastSystemCallRet
> libsyss.dll!ERROR_register_out_of_memory_code+0xda
> MSVCR80.dll!endthreadex+0x3b
> MSVCR80.dll!endthreadex+0xc7
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> ACE.dll!ACE_OS::sema_wait+0xf
> msvcrt.dll: (11) All of these showed up after initializing CLIPS and
> evaluating a rule:
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> msvcrt.dll!endthreadex+0xa9
> kernel32.dll!GetModuleFileNameA+0x1b4
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> msvcrt.dll!endthreadex+0xa9
> kernel32.dll!GetModuleFileNameA+0x1b4
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!WaitForSingleObject+0x12
> msvcrt.dll!endthreadex+0xa9
> kernel32.dll!GetModuleFileNameA+0x1b4
> <first 5 entries on stack same set as our application server>
> ntdll.dll!KiFastSystemCallRet
> kernel32.dll!Sleep+0xf