健身是我的爱好

最近对以前写的tcp网络库做吞吐量测试，gcc O1编译，运行效果很好，可以达到900MiB/s。但是问题来了，当我用gcc O2选项编译网络库，程序一启动就core掉。查看coredump文件，原因大概如下：挂在g_pool.DoSomething();但是在DoSomething()里， this != &g_pool;非常诡异。我对自己的程序还是很有信心，不会

在ae.c文件的aeProcessEvents函数中，针对返回的网络事件有这样的处理代码：int rfired = 0; /* note the fe->mask & mask & ... code: maybe an already processed * event removed an element that fired and we still didn't

Handler是android提供的一个线程之间通信的接口。最开始没注意它，因为只是主线程也就是UI线程使用了handler，而主线程是默认有消息循环的，对开发应用程序是透明的。所以我还误以为handler像是linux信号那样的废材不堪用。linux信号处理程序很受限，推荐做法基本都是在处理程序中设置一个标志，其它循环中处理这标志。甚至在处理程序中使用printf是可能造成单线程

ReplicationRedis replication is a very simple to use and configure master-slave replication that allows slave Redis servers to be exact copies of master servers. The following are some very importan

让我们看下这段程序：很简单的一个重载；如我所愿，程序正常运行结果如下：void func(int)void func(T) [with T = Test]现在，取消最后一行的注释，再次编译。。。出现了如下编译错误：test0.cc: In function ‘void func(T) [with T = short i

引言: 与java等众多支持GC的现代语言不同，C/C++将更多的内存控制权交给程序员，在保证效率的同时，也给了很多犯错的机会。常见的内存泄露、重复释放等等。智能指针大大减少了犯错的机会，简化代码，提高可维护性。常用的智能指针有scope_ptr(c++ 11 unique_ptr)，利用RAII特性，保证资源在作用域失效的时候被释放，也保证异常抛出时栈回滚

昨天终于解决了...1.背景：提供音视频服务的业务随着用户量的上涨，UDP丢包逐渐加剧。其实包量也不大，高峰期每秒不超过10W的UDP包，不应该丢包的。而前辈们的网络底层代码是单线程的，因此决定将网络线程独立出来，以提高效率。2.多线程策略  学过操作系统的应该知道，生产者和消费者的例子。只需要知道1:1的例子即可，这种情形下，可以使用无锁环形缓冲区，避免了mutex的代价(尽管事实上mute

[中文是转的]1、onInterceptTouchEvent()是用于处理事件（类似于预处理，当然也可以不处理）并改变事件的传递方向，也就是决定是否允许Touch事件继续向下（子控件）传递，一但返回True（代表事件在当前的viewGroup中会被处理），则向下传递之路被截断（所有子控件将没有机会参与Touch事件），同时把事件传递给当前的控件的onTouchEvent()处理；返回false

我们经常遇到这样一种情况：服务器A收到客户端的请求：删除该用户的某文件；A需要向文件服务器转发请求，因此首先要把请求保存起来；在未来的某个时刻，文件服务器发来了响应；A再根据响应查找到保存的请求，处理，然后向客户端回复结果：删成功了，或是文件不存在，或是你没有权限等等。是不是有点复杂？(这里没考虑文件服务器超时，自己加timer去，不是这里的重点)。

在用C++编写coroutine基础类的时候，需要参数的传递。而基础类对参数类型一无所知，毕竟参数是与应用相关的。此时，boost::any就派上用场了。编写此类的时候并没有参考boost::any代码(因此功能肯定不如boost::any完善严谨)，写完后做了一下参考，将命名向boost看齐1.  先思考一下Any的用法：Any obj;obj = 5;

在C程序中，带参数的函数调用有几种方式；这里主要介绍三种：stdcall, cdecl, fastcall;    stdcall是WINDOWS API的默认方式；这种方式，参数由被调用者清除，因此产生的代码体略微小一点点(不明显，毕竟就那么几条汇编指令)。但该方式不能应付变长参数的函数，比如printf；因为printf本身不知道传进来多少个参数，参数大小，只能运行时解析获得；而对于v

(2012.05.19补充:尽管-rdynamic选项使得可读性大大提高，但仍然不太好根据二进制地址定位到某行泄露代码；这时使用objdump  -S  exefile 即可)在WINDOWS下检测内存泄露比较容易，毕竟MSDN强大，方法多多；有兴趣可以查看VLD源代码；  前几天无意中从MAN文档中查到linux可以给malloc挂钩子；于是写下了如下检测内存泄露的代码；

1.在官网还是哪儿，我看到了一句关于代码中哈希表的注释:具体记不清楚了，大概有个单词是coarse,意识是说，该哈希表的锁粒度实在是太粗了，以后再细化。 确实，非常粗，多个工作线程对它的互斥竞争比较强烈。 2.解决方案：首先，想把哈希表拆成多个小表，怎么拆呢？

1. 最初看见assoc.c文件，发现了两个哈希表primary_hashtable和old_hashtable，还以为是采用了传说中的perfect hash，再仔细看完该文件，雷！ 2.MEMCACHED只是简单的对哈希表做扩充，在装载因子大于1.5的时候

1. 对这个SLAB内存池实在没什么好说的，比较直白。简单介绍一下各个参数吧。 2. setting的与SLAB相关的参数  chunk_size：这是SLAB所存储的最小对象大小，包括sizeof(item) + key + value。 item_size

1  MEMCACHED的网络线程模型结构和之前公司的网游服务器底层很相似。首先，主线程采用非阻塞ACCEPT，它也只干这一件事情，将新连接按照RR轮转，投递给一个工作线程；投递的方法稍有蹊跷，将新连接PUSH到选定的工作线程的CQ队列中，该队列是线程安全的。

1.memcached参数解读 "p:"  /* TCP port number to listen on */    这是监听套接字所绑定的端口号，对应的变量是settings.port； "U:"  /* UDP port number to listen on */   UDP套接口所绑定的端口号，对应的变量是settings.udpport；   进程会创建两种类型的套接字用于服务。其实还

BOOST 的EPOLL封装，采用了所谓的领导者追随者模式。
我们知道EPOLL_WAIT是不能多线程调用的；
ASIO为了在LINUX下模拟PROACTOR模式，用应用层的数据结构模仿了WINDOWS系统给IOCP实现的完成包队列，
以及IO请求包；
为了模拟IOCP多个工作者线程调用GETQUEUEDCOMPLETEDSTATUS，
由于无法并发EPOLL_WAIT，采用了领导追随模式，做了个大概的模拟。

怎么给人的感觉

1. 编写一个C++类测试：#if !defined(__TEST_H)#define __TEST_Hclass Test{ public: explicit Test(int val = 9); void Print() const; static Test* Clone(int val); private: int m_val;};#endif////////////////#include #in

在asio中有这么一段代码
template <typename Stream>char is_read_buffered_helper(buffered_stream<Stream>* s);template <typename Stream>char is_read_buffered_helper(buffered_read_stream<Stream>* s);struct is_read_buffered_big_type { char data[10]