breakpad

 

因为自己也用minidump捕获异常并回发给自己，但是确实有部分捕捉不到，现在看了breakpad,他也确实多实现了两个c++异常的捕获，暂时还没移植到自己的代码中，也无从知道是否就能全部捕获，不过想来google这种巨无霸，做事情应该很完善

 

看代码，发现breakpad写的挺复杂，远比自己的SetUnhandledExceptionFilter，minidump复杂多了，就算进程内捕获，他都是额外开了线程来处理，更何况还有更复杂的cs模式，他自己的文档里说是为了避免破坏崩溃堆栈，目前自己的知识量不够，还不太明白这个的原因

 

关键点1：

cs结构他使用了命名管道来传输数据，这里没有开辟线程来读写，而是使用了重叠io的做法，

关键点2：

为了进线程间的同步，它使用了cs,mutex,seemaphores,event,给用全了，想来google不会为了显摆的吧，InterlockedIncrement

得好好研究下这几种手段的差异

使用mutex server_alive_来通知客户端服务器活着还是死了，为啥不用event或者semaphores呢？

原因是不管进程是怎么结束的，也不管调用releasemutex或者没有，只要结束了，mutex都会被客户端的waitfor截获，这是

Mutex的特权，其他几个都没这能力

所以mutex的一个典型用法，就是多进程中，服务器createmutex(null,true,"name")建立mutex并拥有，客户端那里判断服务器是否存在就可以用waitfor这个mutex就行了

 

 

他的信号量使用handler_start_semaphore_  handler_finish_semaphore_就完全没头绪了，为啥不用event?这个连猜测都没有啊，悲剧的

现在有猜测了，见下面semaphore红色部分，其实也没大意义，毕竟breakpad里eventhandler类的构造函数和析构始终在一个线程里，或许是一个习惯写法吧，或许这个程序员经常有构造析构不在同一线程的用法，并且event激发状态不能够被保留,这个暂时不能理解啊，代码测试在waitfor前setevent也是有效的，或许操作系统变更了这个？

 

 

顺便记录下这几个内核级同步的区别

mutex:唯一会在线程死掉并没有release的情况下，其他waitfor能得到消息，锁定就拥有所有权，中间多次waitfor也不会阻塞

createmutex(null(安全），false,null),false为不占有，可立刻waitfor

true的话waitfor需要这个线程release

 

semaphore:可设较大的数字，多个waitfor可同时满足条件，锁定后也无法得到所有权，继续waitfor就会卡死

任何线程都可以在任何时间调用releasesemaphore解除锁定？？？？？？？

 CreateSemaphore(NULL, 0, 1, NULL); 0代表当前没有信号，waitfor需release

 

 

event:最具弹性的同步机制，

CreateEvent(NULL,    // Security attributes.  TRUE,    // Manual reset.
                                       FALSE,   // Initial state.
                                       NULL);   // Name.

setevent 设定激发状态，resetevent设定非激发状态

pulseevent,手工reset的话，唤醒所有waitfor,然后设置非激发

                自动，欢迎一个，然后设置为非激发，相当于setevent

 

初始状态为true的话可waitfor到，否则需setevent

另：如果setevent的时候没有waitfor,则setevent无效

 

cs就太简单了，他这里使用InterlockedIncrement配合的，

volatile static LONG instance_count_;

static CRITICAL_SECTION handler_stack_critical_section_;

 

 

然后就是命名管道了，这里用了重叠io和异步调用

  if (!RegisterWaitForSingleObject(&pipe_wait_handle_,
                                   overlapped_.hEvent,
                                   OnPipeConnected,
                                   this,
                                   INFINITE,
                                   kPipeIOThreadFlags)) {
    return false;
  }

  pipe_ = CreateNamedPipe(pipe_name_.c_str(),
                          kPipeAttr,
                          kPipeMode,
                          1,
                          kOutBufferSize,
                          kInBufferSize,
                          0,
                          pipe_sec_attrs_);
  if (pipe_ == INVALID_HANDLE_VALUE) {
    return false;
  }