与Bug战斗的日子

    FTP 客户端
    以下情况程序有可能会挂掉（仅仅只是有可能）：
    1. 服务器关闭
    2.大量数据猛的灌入
     以下情况程序没有问题，不会挂掉：
    1.服务器开启，可以正常进行数据传输时
    2.并行传输任务较少
    3.数据灌入速度较慢
  
     程序crush特征：access violation at ox0000002 ；且出现完全随机
  
     场景1：
     FTP客户端开启，服务器关闭，以 平均50任务每秒的速度加入任务，从第一天下午5：30到第2天下午2：00，程序无任何异常；CPU, MEMORY正常；
  
    场景2：
    测试环境同上，服务器关闭，启动时加入500任务，依次加入，执行至300左右时，crush。前后不足10s。
   
    场景3：
    同上，程序灌入任务，每10ms加入一个单个任务，累计至1000任务左右时 crush.
 
    场景4：
   同上，手工灌入文件，每次500个，累计灌入1万文件，程序OK

  
   重点：随机
  
   难点：无法定位错误的来源
 
   调试过程中的经验：刚开始，有部分 共享数据没有加锁访问，程序crush的几率非常大； 后来所有共享数据访问，全部加锁，程序crush几率大大降低，但仍然会挂掉；也带来一个不好的后果，加入界面用户操作后，易死锁，且随机。
  
   猜测错误根源：多线程的互操作，当某部分数据区已经消亡后，而其他线程继续访问时，便会出现如上的 access violation ；
  
   现在的设计方案是：
  
   MainThread 为界面线程，且 为每一个文件传输任务 创建 一个 WorkThread；WorkThread是一系列的；
   MainThread  维护一个数据队列，保存每个文件传输线程 ，也就是WorkThread的句柄；
   WorkThread中实时更新 MainThread显示数据；
   WorkThread中实时更新数据队列信息；
   MainThread 随时访问 WorkThread 数据；
   MainThread控制WorkThread的创建，但WorkThread的loop完后自动销毁；

   线程间相互操作非常的繁杂；

   下一步的工作是：重写这个模块
 
    修改设计如下：
  
     WorkThread 绝不主动 Callback MainThread 中的函数；
     MainThread poll WorkThread ，然后实时更新界面数据；
     MainThread 主动 join every WorkThread，并控制 WorkThread 的 create & destroy

    明天就去尝试。
  
    一定要搞定这个问题！！！！