JavaScript脚本执行的多线程问题

  ##引论
我们知道典型的Win32应用是由一个进程、一个消息循环和一个窗口过程组成；所有的进程至少有一个线程；由于窗口过程总是在某一个特定的线程中被执行，所以，不论发向这个窗口的被处理的消息是那个线程发出的,最后提现的结果依然是一个线程内的所有的窗口的消息处理是 “串行”、“同步” 的。同时，没有线程的调用执行、消息路由，窗口过程就是“死”的，不会主动跳出来的走路。在计算机世界里面，只有进程、线程是“活”的，能够代码的执行！

##分析
前期和朋友追踪Alert弹出后，HTML页面不能正常关闭的故障，当时，无意间为了验证脚本执行是否多线程、是否线程安全的问题，利用到了VC自带的 Spy++工具，进行观察。Spy++这个工具非常好用，通过它可以看电脑内进程、线程、消息、窗口等。当时就猜测，通过这个手段的印证追踪，最后结果会给我们一点说明，启示控件事件与页面脚本执行，到底是多线程还是单 线程。通过观察，和同事发现IE进程中有一个线程，它创建了很多的窗口，窗口内容里面有类似我们开发程序页面的的文字，拥有很多吻合项，由此我们有理由可以 怀疑、猜测：这个线程就是一般意义上的用户UI线程。 而且，通过源码调试控件所在的“当前线程”的ID，调试结果显示其就是这个用户UI线程；控件所谓的主窗口， 通过这个窗口才能被页面利用script for监听的消息，也是属于这个用户UI线程的。

　进一步，考虑到脚本引擎实际上也是一个实现了特殊COM接口的COM组件( 脚本引擎，也是一个COM对象。它提供IActiveScript和IActiveScriptParse接口的实现，具体介绍 见链接http://www.myfaq.com.cn/A/2005-07-20/165003.html )。 ，我们可以

##结论
加上《COM技术内幕》中讲解的“套间线程”概念 ，我们可以推测脚本引擎和我们自己开发的控件可能属于用一个线程，而这个线程就是我们的我们开发Web程序的客户端主窗口，用户UI线程。由此，我们可以根据上面引论，简单地假定，我们的页面用户操作事件的脚本处理和控件报事件的脚本执行，这个可能貌似“多线程”现象后面的真相，可能是 串行、同步，并非多线程的。即使表现出来的多线程现象，也是“宏观”概念上的，在微观体现为一个个消息顺序、串行处理。因此，我们在一般意义上可以认为是脚本执行一种线程安全 的。因为不管是用户触发事件，还是控件报事件，所带来的脚本执行，我们都可以看成是由同一个线程进行执行代码的，不同窗口间的处理过程。



##将来的事
我们可以发现，由于控件代码的执行实际上可能和 用户UI线程 居于一体，一些与界面无关的执行代码同 用户UI线程 代码的相互剥离将能提高页面效果！
另外，通过，open出来的window在IE进程，通过Spy++观察，体现为两个独立的子线程，而线程间com通讯是小有点代价的，这也是为什么窗口间通讯， 慢的一个原因吧！


##参考资料
《com技术内幕》 第12章 多线程




附注：html页面alert带来的模态，可能比较奇怪，可能与alert的模态内部实现机制有关 。alert后，表现可能不象断点的特性，更像一个alert借助线程的消息循环处理完后，重新跳转goto到alert之后的代码。所以，在这个时间内，线程还能处理其他消息。 但是，由于alert窗口过程的"bug" ，alert窗口过程，拦截了大多数的用户事件，，可能没有阻止的掉 对于控件报的事件 。