Ted Pattison对Matthew Curland中《Advanced Visual Basic》手动列集实现多线程的看法：Ted Pattison著，王新昌等译，《COM+ 与 Visual Basic 6 分布式应用程序设计》（Programming Distributed Applications with COM+ and Microsoft Visual Basic Second Edition）。机械工业出版社，2001.6 第七章 在ＣＯＭ＋应用中共享资源（Chapter 7 Sharing Resources in a COM+ Application） 7.1 共享线程（Sharing Threads） 7.1.2 COM的线程管理模型（COM's Threading Models）译本 P144 -- 机械工业出版社译本 -----------一定不要从Visual Basic中调用CreateThread 如果不对CoInitialize或CoInitializeEx进行显示COM库调用，一个Win32线程就不能参与COM编程。这些函数将线程与单元相关联。对于线程来说，在调用这些函数之前参与任何COM相关活动都是非法而且通常是致命的。幸运的是，COM+运行时在生成一个线程时为你进行这种调用。如果正在创建一个标准EXE或ActiveX EXE项目，Visual Basic运行时在后台进行所需要的CoInitialize调用。 直接使用Win32线程和COM单元是困难的，而且就应用目的来说，这也超过Visual Basic编程语言的能力。但是，当Visual Basic 5第一次发行时，许多程序员试图通过使用Visual Basic的AddressOf这一操作，在Win32API中直接调用CreateThread函数。这些程序员发现它们能成功调用CreateThread，但是它们的应用程序经常奇怪而神秘的终止。 调用CreateThread所存在的问题是，它生成了一个新的对COM或单元一无所知的Win32线程。因此使用这样一个线程在COM对象上调用方法是非法的。这讲导致相当严重问题，因为所有的Visual Basic对象，包括窗体和控件，都是COM对象。这样的对象只能由运行在该对象单元的线程访问。当新生成的线程试图改变某个文本框的值时，应用就会崩溃。这是不要直接从Visual Basic代码中使用CreateThread的一个极好的理由。 一个具有COM线程模型只是的Visual Basic程序员可能试图使问题更进一步。可以通过直接调用像CoInitialize这样的函数来关联一个线程与STA。但是，一当你把一个线程与一个单元关联，复杂性就增加了。例如，你需要编写代码从一个单元到另一个单元传递接口引用（实际上在这一层次传递的是接口指针）。如果你在一个COM方法调用中传递接口引用，代理和占位将自动创建。然而使用其它技术来传递，需求将戏剧性地增加。必须对类型库的两个复杂调用--对CoMarshalInterface的调用将在对象单元中创建一个占位，对CoUnmarshalInterface的调用将在调用者单元中创建一个代理。而且，还必须对COM有足够的了解以确定这些调用何时是必要的。加上与COM+规则和环境相关的复杂性，你应该得出一个重要的结论：一定不要从Visual Basic中调用CreateThread。如果真的需要声称自己的线程，你应该使用C++，而且了解大量有关COM底层管件（plumbing）的知识。 我必须承认这里的讨论仅仅代表了这样的一种观点。Visual Basic世界的一些偶像，如Matthcw Curland，提倡使用上面叙述的方式直接从Visual Basic代码生成线程。在它所写的一本名为《Advanced Visual Basic 6: Power Techniques for Everyday Programs》（由Addison Wesley出版社）的书Matthcw会告诉你这项工作的细节。 如果你对我在第三章里所设计的所有COM细节感到熟悉，并且你正在寻找更深入的探讨，Matthcw的书可以带你走向另一个层次。Matthcw已经对Visual Basic开发小组进行了相当多年的跟踪研究，它具有有关Visual Basic运行是如何与COM库交互的内幕知识。他叙述了许多技术，包括在Visual Basic代码中直接从COM库中调用。 -- 英文原文 ----------------------Never Call CreateThread from Visual Basic A Win32 thread can't participate in COM programming without making an explicit COM library call to either CoInitialize or CoInitializeEx. These functions associate a thread with an apartment. It's illegal and usually fatal for a thread to participate in any COM-related activities before calling one of these functions. Fortunately, the COM+ runtime makes this call for you when it creates a thread. If you're creating a Standard EXE or an ActiveX EXE, the Visual Basic runtime makes all of the required calls to CoInitialize behind the scenes.Working directly with Win32 threads and COM apartments is difficult and, for all practical purposes, beyond the capabilities of the Visual Basic programming language. However, when Visual Basic 5 first shipped, many unfortunate programmers tried to directly call the CreateThread function in the Win32 API by using Visual Basic's new AddressOf operator. The programmers found that they could successfully call CreateThread but that their applications often died strange and mysterious deaths.The problem with calling CreateThread is that it creates a new Win32 thread that knows nothing about COM or apartments. It's therefore illegal to use this thread to invoke a method on a COM object. This creates quite a problem because all Visual Basic objects, including forms and controls, are also COM objects. Such an object can be directly accessed only by the thread running in the object's apartment. When the newly created thread tries to change a value in a text box, the application crashes. This is a pretty good reason to never use CreateThread directly from Visual Basic code.A determined Visual Basic programmer with knowledge of COM's threading models might try to take things to the next level. You can associate a thread with an STA by calling a function such as CoInitialize directly. However, once you associate the thread with an apartment, the complexity increases. For instance, you're typically required to write code for marshaling interface references (which are really interface pointers at this level) from one apartment to another. If you pass the interface references in a COM method call, the proxy and the stub are created automatically. However, if you pass them using another technique, the requirements increase dramatically. You must make two complicated calls to the COM library-a call to CoMarshalInterface to create a stub in the object's apartment and a call to CoUnmarshalInterface to create a proxy in the caller's apartment. What's more, you also have to know enough about COM to decide when these calls are necessary. Add in the complexities related to the rules of COM+ and contexts, and you should come to an important conclusion: Never call CreateThread from Visual Basic. If you really need to spawn your own threads, you should be using C++ and you should know a great deal about the underlying plumbing of COM.I must admit that this entire sidebar is just an opinion. Some of the icons of the Visual Basic world, such as Matt Curland, advocate spawning threads directly from Visual Basic code in the manner I just described. Matt can tell you about the details of this undertaking in a book he's written titled Advanced Visual Basic 6: Power Techniques for Everyday Programs (published by Addison Wesley).If you feel comfortable with all the COM details I covered in Chapter? and you're looking for more in-depth coverage, Matt's book can take you to the next level. Matt has worked on the Visual Basic team for quite a few years and he has intimate knowledge of how the Visual Basic runtime interacts with the COM library. He describes many techniques that involve calling into the COM library directly from Visual Basic code.
http://www.chinaaspx.com/article/vb.net/342.htm
而且在新线程中，访问主线程的对象（如控件、ADO对象等）必须手动做列集处理
那是顶级COM高手才能玩得转的
我试过，ActiveX 似乎并不会自动创建新的线程啊？
http://dev.csdn.net/develop/article/13/13308.shtm
核心思想是用多进程来实现并行运行
第七章 在ＣＯＭ＋应用中共享资源（Chapter 7 Sharing Resources in a COM+ Application）
7.1 共享线程（Sharing Threads）
7.1.2 COM的线程管理模型（COM's Threading Models）译本 P144
-- 机械工业出版社译本 -----------一定不要从Visual Basic中调用CreateThread 如果不对CoInitialize或CoInitializeEx进行显示COM库调用，一个Win32线程就不能参与COM编程。这些函数将线程与单元相关联。对于线程来说，在调用这些函数之前参与任何COM相关活动都是非法而且通常是致命的。幸运的是，COM+运行时在生成一个线程时为你进行这种调用。如果正在创建一个标准EXE或ActiveX EXE项目，Visual Basic运行时在后台进行所需要的CoInitialize调用。
直接使用Win32线程和COM单元是困难的，而且就应用目的来说，这也超过Visual Basic编程语言的能力。但是，当Visual Basic 5第一次发行时，许多程序员试图通过使用Visual Basic的AddressOf这一操作，在Win32API中直接调用CreateThread函数。这些程序员发现它们能成功调用CreateThread，但是它们的应用程序经常奇怪而神秘的终止。
调用CreateThread所存在的问题是，它生成了一个新的对COM或单元一无所知的Win32线程。因此使用这样一个线程在COM对象上调用方法是非法的。这讲导致相当严重问题，因为所有的Visual Basic对象，包括窗体和控件，都是COM对象。这样的对象只能由运行在该对象单元的线程访问。当新生成的线程试图改变某个文本框的值时，应用就会崩溃。这是不要直接从Visual Basic代码中使用CreateThread的一个极好的理由。
一个具有COM线程模型只是的Visual Basic程序员可能试图使问题更进一步。可以通过直接调用像CoInitialize这样的函数来关联一个线程与STA。但是，一当你把一个线程与一个单元关联，复杂性就增加了。例如，你需要编写代码从一个单元到另一个单元传递接口引用（实际上在这一层次传递的是接口指针）。如果你在一个COM方法调用中传递接口引用，代理和占位将自动创建。然而使用其它技术来传递，需求将戏剧性地增加。必须对类型库的两个复杂调用--对CoMarshalInterface的调用将在对象单元中创建一个占位，对CoUnmarshalInterface的调用将在调用者单元中创建一个代理。而且，还必须对COM有足够的了解以确定这些调用何时是必要的。加上与COM+规则和环境相关的复杂性，你应该得出一个重要的结论：一定不要从Visual Basic中调用CreateThread。如果真的需要声称自己的线程，你应该使用C++，而且了解大量有关COM底层管件（plumbing）的知识。
我必须承认这里的讨论仅仅代表了这样的一种观点。Visual Basic世界的一些偶像，如Matthcw Curland，提倡使用上面叙述的方式直接从Visual Basic代码生成线程。在它所写的一本名为《Advanced Visual Basic 6: Power Techniques for Everyday Programs》（由Addison Wesley出版社）的书Matthcw会告诉你这项工作的细节。
如果你对我在第三章里所设计的所有COM细节感到熟悉，并且你正在寻找更深入的探讨，Matthcw的书可以带你走向另一个层次。Matthcw已经对Visual Basic开发小组进行了相当多年的跟踪研究，它具有有关Visual Basic运行是如何与COM库交互的内幕知识。他叙述了许多技术，包括在Visual Basic代码中直接从COM库中调用。
-- 英文原文 ----------------------Never Call CreateThread from Visual Basic A Win32 thread can't participate in COM programming without making an explicit COM library call to either CoInitialize or CoInitializeEx. These functions associate a thread with an apartment. It's illegal and usually fatal for a thread to participate in any COM-related activities before calling one of these functions. Fortunately, the COM+ runtime makes this call for you when it creates a thread. If you're creating a Standard EXE or an ActiveX EXE, the Visual Basic runtime makes all of the required calls to CoInitialize behind the scenes.Working directly with Win32 threads and COM apartments is difficult and, for all practical purposes, beyond the capabilities of the Visual Basic programming language. However, when Visual Basic 5 first shipped, many unfortunate programmers tried to directly call the CreateThread function in the Win32 API by using Visual Basic's new AddressOf operator. The programmers found that they could successfully call CreateThread but that their applications often died strange and mysterious deaths.The problem with calling CreateThread is that it creates a new Win32 thread that knows nothing about COM or apartments. It's therefore illegal to use this thread to invoke a method on a COM object. This creates quite a problem because all Visual Basic objects, including forms and controls, are also COM objects. Such an object can be directly accessed only by the thread running in the object's apartment. When the newly created thread tries to change a value in a text box, the application crashes. This is a pretty good reason to never use CreateThread directly from Visual Basic code.A determined Visual Basic programmer with knowledge of COM's threading models might try to take things to the next level. You can associate a thread with an STA by calling a function such as CoInitialize directly. However, once you associate the thread with an apartment, the complexity increases. For instance, you're typically required to write code for marshaling interface references (which are really interface pointers at this level) from one apartment to another. If you pass the interface references in a COM method call, the proxy and the stub are created automatically. However, if you pass them using another technique, the requirements increase dramatically. You must make two complicated calls to the COM library-a call to CoMarshalInterface to create a stub in the object's apartment and a call to CoUnmarshalInterface to create a proxy in the caller's apartment. What's more, you also have to know enough about COM to decide when these calls are necessary. Add in the complexities related to the rules of COM+ and contexts, and you should come to an important conclusion: Never call CreateThread from Visual Basic. If you really need to spawn your own threads, you should be using C++ and you should know a great deal about the underlying plumbing of COM.I must admit that this entire sidebar is just an opinion. Some of the icons of the Visual Basic world, such as Matt Curland, advocate spawning threads directly from Visual Basic code in the manner I just described. Matt can tell you about the details of this undertaking in a book he's written titled Advanced Visual Basic 6: Power Techniques for Everyday Programs (published by Addison Wesley).If you feel comfortable with all the COM details I covered in Chapter? and you're looking for more in-depth coverage, Matt's book can take you to the next level. Matt has worked on the Visual Basic team for quite a few years and he has intimate knowledge of how the Visual Basic runtime interacts with the COM library. He describes many techniques that involve calling into the COM library directly from Visual Basic code.
编译成exe后Timer就不会暂停了
网络编程？WinSock控件？
当WinSock控件收到数据的时候，不是会触发DataArrival事件吗
想耍多线程就别耍VB