K.O Angel 的专栏

bootstrap出现错误针对文件：dos2unix bootstrap acinclude.m4 codeblocks.pc.in configure.in 执行MAKE到后面出现编译的时候出现can not be used when making a shared object; recompile with -fPIC错误解决办法./configure –with-pic –

介绍构想的起因，是两年前对于RPC系统的热衷，包括我们所能看到的机遇UDP的RPC引擎，最出名的莫过于RAKNET这样的尖端库了，OK为什么还要重新做一套RPC呢？最近一年的开发中我发现RAKNET无法在国内轻易的使用，尤其是其因为某些硬件故障导致的断开以及数据异常，基本上是我无法忍受的。之后开始我持续希望对于服务器端，客户端隐藏实际开发中的各种网络层的问题，那么就是RPC了，而普

自己弄了下 虽然可以用，但是bjam没安装成功，同事说他可以，把安装步骤发我。按着他的步骤在新的一台机子上安装，和我自己的安装结果是一样的，，，先把安装步骤记录一下，以后有空再查查吧，为什么呀，不成功？1. 安装luaa: make linuxb: make install2. 安装boost库a: cd boost_1_46_1/tools/build/v2b:

很多服务器端设计者，很少会考虑到服务器永久存活或热替换的问题，貌似真的很少其中永久存活最大的理论支持就是，我们如何真正的保证一组服务器持续的存在，即便宕机？其实没有人能保证自己写的代码那么完美无瑕，因为它的存在就是必须去崩溃，必须暴露更多的错误才能更加完美无瑕，所以除了自己有大量的测试代码外，其实对于程序本身的测试很多是无法达到的，那么我们就需要更多的外部支持，那么在实际运营中，最好的

我最近由于无法忍受VS2010以及NETBEANS 7.1的内存占用，我表示我必须采用其他方式来替代这种开发模型。结果是让我得到了以下的几种组合，在不变动NETBEANS的PROJECT的情况下，我们有了。以下均集合winscp同步源码至目录1、VS2010 and Netbeans 优点：可以快速开发项目，并且有良好的提示体系。缺点：内存占用巨大，很卡。2、slicked

一、前言以下内容仅为理论，并未实践，考虑在现在的项目中实践或做一个测试的DEMO，见谅见谅。但开了一个不错的思路？？？我绝对不是第一个想到这个理论的，只是我突然觉得它有改进的余地。请不要再一般的环境中使用以下技术，对一般程序而言绝对没用，请在大量使用内存并希望可以通过预申请内存达到稳定的应用程序中使用以下理论。二、选择库我们常常有使用freelist的习惯，尤其在服务器端中使用

recursive_mutex会减少死锁几率？恩看上去的确如此，但是事实上呢？我们从BOOST的官方逻辑去理解：recursive_mutex类可多次进入锁，这样在递归时可以避免一次死锁的几率，这是原本BOOST中所体现的一种思想，OK，为什么我们要质疑其问题。最近项目中大量使用recursive_mutex锁作为主力锁，但是奇迹般的发现，一个递归函数仍然存在死锁（已做优化，换为mutex

最近发现在腾讯的CVM上，服务器总是平凡的死锁后查明真像为当你发生sig 11的异常时，会进入处理函数 signalHandler同时此时生成相应的dump file时间，在这里我调用了函数 localtime 函数。此函数会在内部实现时调用malloc函数，而此函数有锁是不可重入函数，所以这个时候你会发现dump写不出来，而且所有程序死锁了。实际上从程序角度来看此

曾几何时我们可以肆无忌惮的对sprintf传入BYTE等类型作为参数，只要你指定的为%D但是boost format不可以，当你发生类型截断，错误，异常，请尽快查看你传入的类型是否为Byte因为format会将GoByte当做char来打印，请诸位务必注意，切记 切记