因为自己也用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;
}