You cannot call ActiveX Scripting engine methods from non-base threads in Visual C++ (222837)
The information in this article applies to:
- Microsoft Visual C++, 32-bit Enterprise Edition 6.0
- Microsoft Visual C++, 32-bit Professional Edition 6.0
- Microsoft Visual C++, 32-bit Learning Edition 6.0
- Microsoft Visual C++ 2005 Express Edition
- Microsoft Visual C++ .NET (2003)
- Microsoft Visual C++ .NET (2002)
This article was previously published under Q222837 Note Microsoft Visual C++ .NET 2002 and Microsoft Visual C++ .NET 2003 support both the managed code model that is provided by the Microsoft .NET Framework and the unmanaged native Microsoft Windows code model. The information in this article applies only to unmanaged Visual C++ code. Microsoft Visual C++ 2005 supports both the managed code model that is provided by the Microsoft .NET Framework and the unmanaged native Microsoft Windows code model. SYMPTOMS When an ActiveX Scripting host calls a method on an ActiveX
Scripting engine, such as Visual Basic Script or Java Script, from a thread
other than the one that created the engine, the call might fail with HRESULT
E_FAIL or E_UNEXPECTED. CAUSE After an ActiveX Scripting engine has received a reference
to its host by calling the IActiveScript::SetScriptSite method, the scripting
engine can no longer accept calls from non-base threads. This happens because
the scripting engine checks the thread that makes each call and rejects any
calls from non-base threads. NOTE: The base thread is the one that called
IActiveScript::SetScriptSite. RESOLUTION After the IActiveScript::SetScriptSite method has been
called, you cannot call scripting engine methods on non-base thread, however,
there are two notable exceptions to this rule: - You can call the IActiveScript::InterruptScriptThread
method from any thread, thus giving the host a chance to stop a script that has
become stuck.
- You can call the IActiveScript::Clone method from any
thread, thus giving the host the ability to set up a standard scripting engine
and then replicate it for multiple job runs.
STATUS This behavior is by design.
ActiveX Scripting
engines were designed to behave this way because a truly free-threaded
scripting engine would require that every single method in the engine be
shielded with critical sections, mutexes, or some other synchronization method.
This would result in massive overhead and slow downs. REFERENCES For additional information about ActiveX Scripting Hosts,
please see the following articles in the Microsoft Knowledge Base: 182946 PRB: InterruptScriptThread Causes Invalid Page Fault in OLEAUT32
183648 PRB: InterruptScriptThread Causes Invalid Page Fault in OLEAUT32
168214 SAMPLE: MFCAxs.exe Implements an Active Script Host Using MFC
Modification Type: | Major | Last Reviewed: | 1/5/2006 |
---|
Keywords: | kbtshoot kbActiveXScript kbprb KB222837 kbAudDeveloper |
---|
|