发现前段时间写的那些代码很不稳定，总是会崩溃！今天被人翻出来批判了一把，惭愧啊！
问题出在多线程上。一个编辑器对象创建后，会创建一个新的线程来分析编辑器中的内容，然后把分析后的结果保存在成员变量的。这时如果在保存结果之前，编辑器对象已经被销毁了，则访问成员变量也是不可行的，所以我在编辑器对象被销毁的时刻（析构函数中）强行打断线程的执行。
另一个问题，同样是编辑器对象创建后，要创建一个新的线程来分析编辑器的内容，然后根据分析后的结果，来对编辑器做些特定的操作。这里我使用了boost::signals2来进行通知，其实这不是必要的，用boost::function作为回调函数也是可以达到目的的，毕竟在我看来，使用boost::signals2的区别只在于它可以绑定多个接收槽。结果问题来了，boost::signals2的自动对象管理似乎只能依赖于boost::shared_ptr的对象生命期管理，而这boost::shared_ptr的使用在我这种情况下就比较棘手了，原来只是把该对象作为一个聚合对象实现，而似乎boost::shared_ptr的使用最好是从一开始就是在堆上new出一个来，并以boost::shared_ptr的形式保存起来，现在要改，也是有不小的工作量。说实话，在我看来，这样的接口，还不如boost::signals的trackable基类的实现好呢。而且另外还有个问题是，就算这信号-槽的机制真正正确起作用了，信号过来后，仍然是在一个工作线程中对编辑器对象进行一些操作，而这些操作进行到半途，如果编辑器对象突然被销毁了，那也是不行的，所在不得不在这个接收槽的处理过程中也加入线程中断的检测。
这样，貌似理论上两个问题都可以解决了。于是用boost::thread实现吧，它有比较方便的创建新线程的接口，可以方便地把一些参数传递给线程函数，这真是一个巨大的进步。其次，它有interrupt接口，可以在让线程被中断，有join/timed_join接口，可以绅士地等待线程结束。似乎一切都正是为我解决上面这两个问题问题准备的！但是，问题仍然困扰着我，居然，偶尔的interrupt并不能让boost::this_thread::interrupt_point抛出异常来，而这个“偶尔”实在在是太频繁了！还有，居然，似乎，偶尔join并没有真的等到线程结束就返回了！现有，这个join在等待的时候，会有死锁的现象！
我狂分特啊！到底是哪里出错了，而且这样的问题还都不是必然重现的，郁闷哇！
支付宝扫一扫
微信扫一扫