Linux：让内存不再泄漏(转)(2012-2-10 10:21:00)

　　作者：秋冰

　　本文将介绍内存泄漏的检测方法以及现在可以使用的工具。针对内存泄漏的问题，本文提供足够的信息，使我们能够在不同的工具中做出选择。

　　内存泄漏

　　在此，谈论的是程序设计中内存泄漏和错误的问题，不过，并不是所有的程序都有这一问题。首先，泄漏等一些内存方面的问题在有的程序语言中是不容易发生的。这些程序语言一般都认为内存管理太重要了，所以不能由程序员来处理，最好还是由程序语言设计者来处理这些问题，这样的语言有Perl、Java等等。

　　然而，在一些语言(最典型的就是C和C++)中，程序语言的设计者也认为内存管理太重要，但必需由开发人员自己来处理。内存泄漏指的是程序员动态分配了内存，但是在使用完成后却忘了将其释放。除了内存泄漏以外，在开发人员自己管理内存的开发中，缓冲溢出、悬摆指针等其它一些内存的问题也时有发生。

　　问题缘何产生

　　为了让程序能够处理在编译时无法预知的数据占用内存的大小，所以程序必需要从操作系统实时地申请内存，这就是所谓的动态内存。这时候，就会出现程序申请到内存块并且使用完成后，没有将其归还给操作系统的错误。更糟的情况是所获取的内存块的地址丢失，从而系统无法继续识别、定位该内存块。还有其它的问题，比如试图访问已经释放的指针(悬摆指针)，再如访问已经被使用了的内存(内存溢出)的问题。

　　后果不容忽视

　　对于那些不常驻内存的程序来说，由于执行过程很短，所以即使有漏洞可能也不会导致特别严重的后果。不过对于一些常驻内存的程序(比如Web服务器Apache)来说，如果出现这样的问题，后果将非常严重。因为有问题的程序会不断地向系统申请内存，并且不释放内存，最终可能导致系统内存耗尽而导致系统崩溃。此外，存在内存泄漏问题的程序除了会占用更多的内存外，还会使程序的性能急剧下降。对于服务器而言，如果出现这种情况，即使系统不崩溃，也会严重影响使用。

　　悬摆指针会导致一些潜在的隐患，并且这些隐患不容易暴发。它非常不明显，因此很难被发现。在这三种存在的问题形式中，缓冲溢出可能是最危险的。事实上，它可能会导致很多安全性方面的问题(一个安全的程序包含很多要素，但是最重要的莫过于小心使用内存)。正如上面所述，有时也会发生同一内存块被多次返还给系统的问题，这显然也是程序设计上的错误。一个程序员非常希望知道在程序运行的过程中，使用内存的情况，从而能够发现并且修正问题。

　　如何处理

　　现在已经有了一些实时监测内存问题的技术。内存泄漏问题可以通过定时地终止和重启有问题的程序来发现和解决。在比较新的Linux内核版本中，有一种名为OOM(Out Of Memory )杀手的算法，它可以在必要时选择执行Killed等程序。悬摆指针可以通过定期对所有已经返还给系统的内存置零来解决。解决内存溢出问题的方法则多种多样。

　　事实上，在程序运行时来解决这些问题，显然要麻烦得多，所以我们希望能够在开发程序时就发现并解决这些问题。下面介绍一些可用的自由软件。

　　工具一：垃圾回收器(GC)

?　≡贕CC(下载)工具包中，有一个“垃圾回收器(GC)”，它可以轻松检测并且修正很多的内存问题。目前该项目由HP的Hans-J.Boehm负责。

　　使用的技术

　　GC使用的是名为Boehm-Demers-Weiser的可以持续跟踪内存定位的技术。它的算法通过使用标准的内存定位函数来实现。程序使用这些函数进行编译，然后执行，算法就会分析程序的操作。该算法非常著名并且比较容易理解，不会导致问题或者对程序有任何干扰。

　　性能

　　该工具有很好的性能，故可以有效提高程序效率。其代码非常少并且可以直接在GCC中使用。

　　该工具没有界面，使用起来比较困难，所以要想掌握它还是要花一些工夫的。一些现有的程序很有可能无法使用这个编辑器进行配置。此外，为了让所有的调用能被捕获，所有的内存调用(比如malloc()和free())都必须要使用由GC提供的相应函数来代替。我们也可以使用宏来完成这一工作，但还是觉得不够灵活。

　　结论

　　如果你希望能够有跨平台(体系结构、操作系统)的解决方案，那么就是它了。

　　工具二：Memprof

　　Memprof（下载）是一个非常具有吸引力且非常易于使用的软件，它由Red Hat的Owen Talyor创立。这个工具是用于GNOME前端的Boehm-Demers-Weiser垃圾回收器。

　　使用的技术

　　就其核心技术来说，Memprof和上面提到的GC没有什么本质的不同。不过在实现这一功能时，它是从程序中捕获所有的内存请示并且实时将其重定位到垃圾回收器。

　　性能

　　该工具的性能非常不错，其GUI设计得也不错(如图1所示)。这个工具直接就可以执行，并且其工作起来无需对源代码进行任何修改。在程序执行时，这个工具会以图形化的方式显示内存的使用情况，以帮助你了解程序运行过程中内存的申请情况（如图1）。

　　

　　图1 Memprof的GUI

　　该工具目前只能运行于x86和PPC体系结构之上的Linux系统之中。如果你需要用于其它的平台，应该想想使用其它的工具。该工具不是GTK应用程序，所以需要一个完整的GNOME环境。这样就使得其不能灵活用于所有的地方。此外，该工具的开发工作进展得也比较缓慢(现在是0.4.1版)。

　　结论

　　如果你喜欢GUI工具并且不介意只能用于Linux以及GNOME之下，该工具应该可以说是非常不错。

　　工具三：Valgrind

　　Valgrind(http://developer.kde.org/~sewardj/)是一个致力于解决所有内存问题的程序，而内存泄漏只不过是其中的问题之一而已。该工具的开发人员是Julian Seward(以Bzip2和Cacheprof而闻名)。该工具宣称自己“是专门致力于解决x86 Linux中开放源代码的内存问题”，事实上，它的确做到了自己的宣言。此外，它还可以描述CPU缓存的使用情况，不过这一功能并不常用。

　　使用的技术

　　在这个程序中使用的技术非常复杂，不过其文档非常丰富和完整(http://developer.kde.org/~sewardj/docs/techdocs.html)。程序分配的每一字节的内存都被一个有九位的状况字跟踪，其目的是用于识别其意图。这种做法大大加重了系统的负担。

　　性能

　　这个工具是我们这儿介绍的三款中性能最差的一个，原因是显而易见的。该工具提供的信息细节是三个工具中最丰富的，因而速度也是最慢的。除了一些常见的问题外，该工具还可以发现内存其它的一些问题，甚至一些POSIX线程方面的问题。缓冲的信息对于大部分程序来说似乎没有必要，不过它是一个查看程序性能的很好方式。对于Valgrind来说，值得一提的就是其开发速度非常快，其开发社团也非常活跃。事实上，在Valgrind的主页上作者甚至有一句话：“如果你在使用Valgrind过程中有任何问题，请不要介意，给我发邮件吧”。

　　不过，该工具是专门用于x86的。其界面是纯命令行方式，但是其可用性非常好。该工具可以直接在二进制下运行，所以在使用时并不需要对其进行重新编译。不过要熟练掌握它，还是需要使用者进行一番努力的。此外，虽然该工具曾经使用于Mozilla、OpenOffice等一些大的线程程序，但该工具对线程的支持并不完善。我想如果该工具要是有一个GUI界面，将会赢得更多人的青睐。

　　结论

　　如果你使用x86，对自己的代码非常了解并且不介意使用命令行方式，那么这个程序将是你的至爱。

　　如果我在此介绍的三款工具你都不喜欢，那也没有关系，可在下面站点中找到很多检测内存错误的工具：http://www.sslug.dk/emailarkiv/bog/2001_08/msg00030.html。此外，还有一些商业工具，比如Purify、Geodesic等。在此就不详细介绍。

 

没有new, 内存又泄漏了.杯具

阅读全文(588) | 评论:0 | 复制链接

Linux2.6内核epoll介绍(转)(2012-1-29 10:07:00)

http://blog.csdn.net/rstevens/archive/2007/10/30/1858067.aspx

http://hi.baidu.com/jmlover/blog/item/24c28b131e6b48d7f7039ee6.html
http://hi.baidu.com/jmlover/blog/item/e64df724f12926348744f91b.html



名词解释：man epoll之后，得到如下结果：

NAME
epoll - I/O event notification facility

SYNOPSIS
#include <sys/epoll.h>

DEscrīptION
epoll is a variant of poll(2) that can be used either as Edge or Level
Triggered interface and scales well to large numbers of watched fds.
Three system calls are provided to set up and control an epoll set:
epoll_create(2), epoll_ctl(2), epoll_wait(2).

An epoll set is connected to a file descrīptor created by epoll_create(2).   Interest for certain file descrīptors is then registered via
epoll_ctl(2). Finally, the actual wait is started by epoll_wait(2).

其实，一切的解释都是多余的，按照我目前的了解，EPOLL模型似乎只有一种格式，所以大家只要参考我下面的代码，就能够对EPOLL有所了解了，代码的解释都已经在注释中：

while (TRUE)
{
int nfds = epoll_wait (m_epoll_fd, m_events, MAX_EVENTS, EPOLL_TIME_OUT);//等待EPOLL事件的发生，相当于监听，至于相关的端口，需要在初始化EPOLL的时候绑定。
if (nfds <= 0)
continue;
m_bOnTimeChecking = FALSE;
G_CurTime = time(NULL);
for (int i=0; i<nfds; i++)
{
try
{
if (m_events[i].data.fd == m_listen_http_fd)//如果新监测到一个HTTP用户连接到绑定的HTTP端口，建立新的连接。由于我们新采用了SOCKET连接，所以基本没用。
{
OnAcceptHttpEpoll ();
}
else if (m_events[i].data.fd == m_listen_sock_fd)//如果新监测到一个SOCKET用户连接到了绑定的SOCKET端口，建立新的连接。
{
OnAcceptSockEpoll ();
}
else if (m_events[i].events & EPOLLIN)//如果是已经连接的用户，并且收到数据，那么进行读入。
{
OnReadEpoll (i);
}

OnWriteEpoll (i);//查看当前的活动连接是否有需要写出的数据。
}
catch (int)
{
PRINTF ("CATCH捕获错误\n");
continue;
}
}
m_bOnTimeChecking = TRUE;
OnTimer ();//进行一些定时的操作，主要就是删除一些断线用户等。
}

其实EPOLL的精华，按照我目前的理解，也就是上述的几段短短的代码，看来时代真的不同了，以前如何接受大量用户连接的问题，现在却被如此轻松的搞定，真是让人不得不感叹。

今天搞了一天的epoll，想做一个高并发的代理程序。刚开始真是郁闷,一直搞不通，网上也有几篇介绍epoll的文章。但都不深入，没有将一些注意的地方讲明。以至于走了很多弯路，现将自己的一些理解共享给大家,以少走弯路。

epoll用到的所有函数都是在头文件sys/epoll.h中声明，有什么地方不明白或函数忘记了可以去看一下。
epoll和select相比，最大不同在于:

1epoll返回时已经明确的知道哪个sokcet fd发生了事件，不用再一个个比对。这样就提高了效率。
2select的FD_SETSIZE是有限止的，而epoll是没有限止的只与系统资源有关。

1、epoll_create函数
函数声明：int epoll_create(int size)
该 函数生成一个epoll专用的文件描述符。它其实是在内核申请一空间，用来存放你想关注的socket fd上是否发生以及发生了什么事件。size就是你在这个epoll fd上能关注的最大socket fd数。随你定好了。只要你有空间。可参见上面与select之不同2.

22、epoll_ctl函数
函数声明：int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
该函数用于控制某个epoll文件描述符上的事件，可以注册事件，修改事件，删除事件。
参数：
epfd：由 epoll_create 生成的epoll专用的文件描述符；
op：要进行的操作例如注册事件，可能的取值EPOLL_CTL_ADD 注册、EPOLL_CTL_MOD 修 改、EPOLL_CTL_DEL 删除

fd：关联的文件描述符；
event：指向epoll_event的指针；
如果调用成功返回0,不成功返回-1

用到的数据结构
typedef union epoll_data {
void *ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t;

struct epoll_event {
__uint32_t events; /* Epoll events */
epoll_data_t data; /* User data variable */
};


如：
struct epoll_event ev;
//设置与要处理的事件相关的文件描述符
ev.data.fd=listenfd;
//设置要处理的事件类型
ev.events=EPOLLIN|EPOLLET;
//注册epoll事件
epoll_ctl(epfd,EPOLL_CTL_ADD,listenfd,&ev);


常用的事件类型:
EPOLLIN ：表示对应的文件描述符可以读；
EPOLLOUT：表示对应的文件描述符可以写；
EPOLLPRI：表示对应的文件描述符有紧急的数据可读
EPOLLERR：表示对应的文件描述符发生错误；
EPOLLHUP：表示对应的文件描述符被挂断；
EPOLLET：表示对应的文件描述符有事件发生；


3、epoll_wait函数
函数声明:int epoll_wait(int epfd,struct epoll_event * events,int maxevents,int timeout)
该函数用于轮询I/O事件的发生；
参数：
epfd:由epoll_create 生成的epoll专用的文件描述符；
epoll_event:用于回传代处理事件的数组；
maxevents:每次能处理的事件数；
timeout:等待I/O事件发生的超时值(单位我也不太清楚)；-1相当于阻塞，0相当于非阻塞。一般用-1即可
返回发生事件数。


用法如下：

/*build the epoll enent for recall */
struct epoll_event ev_read[20];
int nfds = 0; //return the events count
nfds=epoll_wait(epoll_fd,ev_read,20, -1);
for(i=0; i
{
if(ev_read[i].data.fd == sock)// the listener port hava data
......

epoll_wait运行的原理是
等侍注册在epfd上的socket fd的事件的发生，如果发生则将发生的sokct fd和事件类型放入到events数组中。
并 且将注册在epfd上的socket fd的事件类型给清空，所以如果下一个循环你还要关注这个socket fd的话，则需要用epoll_ctl(epfd,EPOLL_CTL_MOD,listenfd,&ev)来重新设置socket fd的事件类型。这时不用EPOLL_CTL_ADD,因为socket fd并未清空，只是事件类型清空。这一步非常重要。
俺最开始就是没有加这个，白搞了一个上午。

4单个epoll并不能解决所有问题，特别是你的每个操作都比较费时的时候，因为epoll是串行处理的。
所以你还是有必要建立线程池来发挥更大的效能。

//////////////////////////////////////////////////////////////////////////////
man中给出了epoll的用法，example程序如下：
for(;;) {
nfds = epoll_wait(kdpfd, events, maxevents, -1);

for(n = 0; n < nfds; ++n) {
if(events[n].data.fd == listener) {
client = accept(listener, (struct sockaddr *) &local,
&addrlen);
if(client < 0){
perror("accept");
continue;
}
setnonblocking(client);
ev.events = EPOLLIN | EPOLLET;
ev.data.fd = client;
if (epoll_ctl(kdpfd, EPOLL_CTL_ADD, client, &ev) < 0) {
fprintf(stderr, "epoll set insertion error: fd=%d\n",
client);
return -1;
}
}
else
do_use_fd(events[n].data.fd);
}
}
此时使用的是ET模式，即，边沿触发，类似于电平触发，epoll中的边沿触发的意思是只对新到的数据进行通知，而内核缓冲区中如果是旧数据则不进行通知，所以在do_use_fd函数中应该使用如下循环，才能将内核缓冲区中的数据读完。
while (1) {
len = recv(*******);
if (len == -1) {
if(errno == EAGAIN)
break;
perror("recv");
break;
}
do something with the recved data........
}

在上面例子中没有说明对于listen socket fd该如何处理，有的时候会使用两个线程，一个用来监听accept另一个用来监听epoll_wait，如果是这样使用的话，则listen socket fd使用默认的阻塞方式就行了，而如果epoll_wait和accept处于一个线程中，即，全部由epoll_wait进行监听，则，需将 listen socket fd也设置成非阻塞的，这样，对accept也应该使用while包起来（类似于上面的recv），因为，epoll_wait返回时只是说有连接到来 了，并没有说有几个连接，而且在ET模式下epoll_wait不会再因为上一次的连接还没读完而返回，这种情况确实存在，我因为这个问题而耗费了一天多 的时间，这里需要说明的是，每调用一次accept将从内核中的已连接队列中的队头读取一个连接，因为在并发访问的环境下，有可能有多个连接“同时”到 达，而epoll_wait只返回了一次。

唯一有点麻烦是epoll有2种工作方式:LT和ET。

LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你 的，所以，这种模式编程出错误可能性要小一点。传统的select/poll都是这种模型的代表．

ET (edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述 符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致 了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once),不过在TCP协议中，ET模式的加速效用仍需要更多的benchmark确认。

---

问题关键：
当epoll_wait返回之后，数据处理与新数据到达之间是并行关系。
例如：当一个socket fd有数据可读时，recv(fd)的同时，该fd可能又有新的数据到达，而这些新的数据在老数据读完前不会导致fd的状态改变，对epoll没有影响。
在ET模式下，必须一直调用recv()直到返回-1，产生一次fd的状态改变后，新数据才能使epoll继续有效。
对于accept()，情况也一样，epoll_wait()返回之后，如果又有新的连接进来，对epoll没有任何影响，epoll不会在下一次wait时返回，
必须while(accept(listener))，直到listener 产生状态改变后，新连接才能使epoll继续有效。


man epoll中有如下介绍：

Level-Triggered and Edge-Triggered
The epoll event distribution interface is able to  behave  both  as  edge-triggered
(ET)  and  level-triggered  (LT).  The difference between the two mechanisms can be
described as follows.  Suppose that this scenario happens:

1. The file descriptor that represents the read side  of  a  pipe  (rfd)  is  added
inside the epoll device.

2. A pipe writer writes 2 kB of data on the write side of the pipe.

3. A call to epoll_wait(2) is done that will return rfd as a ready file descriptor.

4. The pipe reader reads 1 kB of data from rfd.

5. A call to epoll_wait(2) is done.

If the rfd file descriptor has been added to the epoll interface using the  EPOLLET
(edge-triggered)  flag, the call to epoll_wait(2) done in step 5 will probably hang
despite the available data still present in the file input  buffer;  meanwhile  the
remote  peer  might be expecting a response based on the data it already sent.  The
reason for this is that edge-triggered mode only delivers events when changes occur
on  the  monitored  file descriptor.  So, in step 5 the caller might end up waiting
for some data that is already present inside the input buffer.  In the above  exam‐
ple, an event on rfd will be generated because of the write done in 2 and the event
is consumed in 3.  Since the read operation done in 4 does not  consume  the  whole
buffer data, the call to epoll_wait(2) done in step 5 might block indefinitely.

An  application that employs the EPOLLET flag should use non-blocking file descrip‐
tors to avoid having a blocking read or write starve a task that is handling multi‐
ple  file  descriptors.  The suggested way to use epoll as an edge-triggered (EPOL‐
LET) interface is as follows:

i   with non-blocking file descriptors; and

ii  by waiting for an event only after read(2) or write(2) return EAGAIN.

By contrast, when used as a level-triggered interface (the default, when EPOLLET is
not specified), epoll is simply a faster poll(2), and can be used wherever the lat‐
ter is used since it shares the same semantics.

Since even with the edge-triggered epoll multiple  events  can  be  generated  upon
receipt  of multiple chunks of data, the caller has the option to specify the EPOL‐
LONESHOT flag, to tell epoll to disable the associated file  descriptor  after  the
receipt  of  an event with epoll_wait(2).  When the EPOLLONESHOT flag is specified,
it is the caller's responsibility to rearm the file descriptor  using  epoll_ctl(2)
with EPOLL_CTL_MOD.

“即使使用ET模式的epoll，在收到多个chunk的数据的时候仍然会产生多个事件”
不知道这里是指在老数据读完后收到新数据产生event，还是老数据读完之前收到新的chunk data也会产生event？

关于recv()：
要是你提供的接收Buffer过小，TCP将返回实际接收的长度，余下的还可以收，而UDP不同的是，余下的数据被丢弃并 返回 WSAEMSGSIZE错误。要是你提供的Buffer佷大，那么TCP可能收到的就是多个发包，你必须分离它们。
还有就是当Buffer太小，而 一次收不完Socket内部的数据，那么Socket接收事件(OnReceive)，可能不会再触发，使用事件方式进行接收时，密切注意这点。这些特性就是体现了流和数据包的区别。


~~end~~

阅读全文(656) | 评论:1 | 复制链接

eth0 设备的 MAC 地址与预想的不符(转)(2012-1-19 17:32:00)

今天打开虚拟机要做测试，改了IP地址重起network发现报“eth0设备的MAC地址与预想的不符，忽略”错误，上网一查说是因为以前网卡的信息与当前网卡信息记录不符造成，于是按照网上说法进行修改。 vi /etc/sysconfig/network-scripts/ifcfg-eth0后把最后一项的MAC改成当前的MAC信息，重起就好了。 问题很容易解决不过我反复弄了好几次才搞好，有一个这样的疑惑一直不解： 第一次改ifcfg-eth0中的MAC信息前，我是ifconfig命令查看的eth0信息： 察看后把原来的ifcfg-eth0中的MAC信息改好后，service network restart后发现依然报“eth0设备的MAC地址与预想的不符，忽略”错误，于是： 第二次改ifcfg-eth0中的MAC信息，我是ip address show命令查看的eth0信息： 这次改完ifcfg-eth0的MAC信息重起后OK，看来我的MAC是小写的才对，所以第二次没有继续报错。疑惑阿！为什么不同命令看到的MAC信息会有大小写之分内？大牛有知道原因请告知小弟阿。

阅读全文(488) | 评论:0 | 复制链接

GCC 提供的原子操作(2012-1-5 10:50:00)

gcc从4.1.2提供了__sync_*系列的built-in函数，用于提供加减和逻辑运算的原子操作。

其声明如下：

这两组函数的区别在于第一组返回更新前的值，第二组返回更新后的值。

type可以是1,2,4或8字节长度的int类型，即：

后面的可扩展参数(...)用来指出哪些变量需要memory barrier,因为目前gcc实现的是full barrier（类似于linux kernel 中的mb(),表示这个操作之前的所有内存操作不会被重排序到这个操作之后）,所以可以略掉这个参数。



这两个函数提供原子的比较和交换，如果*ptr == oldval,就将newval写入*ptr,
第一个函数在相等并写入的情况下返回true.
第二个函数在返回操作之前的值。


发出一个full barrier.

关于memory barrier,cpu会对我们的指令进行排序，一般说来会提高程序的效率，但有时候可能造成我们不希望得到的结果，举一个例子，比如我们有一个硬件设备，它有4个寄存器，当你发出一个操作指令的时候，一个寄存器存的是你的操作指令（比如READ），两个寄存器存的是参数（比如是地址和size），最后一个寄存器是控制寄存器，在所有的参数都设置好之后向其发出指令，设备开始读取参数，执行命令，程序可能如下：

如果最后一条write1被换到了前几条语句之前，那么肯定不是我们所期望的，这时候我们可以在最后一条语句之前加入一个memory barrier,强制cpu执行完前面的写入以后再执行最后一条：

memory barrier有几种类型：
    acquire barrier : 不允许将barrier之后的内存读取指令移到barrier之前（linux kernel中的wmb()）。
    release barrier : 不允许将barrier之前的内存读取指令移到barrier之后 (linux kernel中的rmb())。
    full barrier    : 以上两种barrier的合集(linux kernel中的mb())。


还有两个函数：

type __sync_lock_test_and_set (type *ptr, type value, ...)
   将*ptr设为value并返回*ptr操作之前的值。

void __sync_lock_release (type *ptr, ...)
     将*ptr置0


示例程序：

阅读全文(470) | 评论:1 | 复制链接

linux 套接字选项定义(2012-1-5 10:49:00)

1.closesocket（一般不会立即关闭而经历TIME_WAIT的过程）后想继续重用该socket：
BOOL bReuseaddr=TRUE;
setsockopt(s,SOL_SOCKET ,SO_REUSEADDR,(const char*)&bReuseaddr,sizeof(BOOL));

2. 如果要已经处于连接状态的soket在调用closesocket后强制关闭，不经历
TIME_WAIT的过程：
BOOL bDontLinger = FALSE;
setsockopt(s,SOL_SOCKET,SO_DONTLINGER,(const char*)&bDontLinger,sizeof(BOOL));

3.在send(),recv()过程中有时由于网络状况等原因，发收不能预期进行,而设置收发时限：
int nNetTimeout=1000;//1秒
//发送时限
setsockopt(socket，SOL_S0CKET,SO_SNDTIMEO，(char *)&nNetTimeout,sizeof(int));
//接收时限
setsockopt(socket，SOL_S0CKET,SO_RCVTIMEO，(char *)&nNetTimeout,sizeof(int));

4.在send()的时候，返回的是实际发送出去的字节(同步)或发送到socket缓冲区的字节
(异步);系统默认的状态发送和接收一次为8688字节(约为8.5K)；在实际的过程中发送数据
和接收数据量比较大，可以设置socket缓冲区，而避免了send(),recv()不断的循环收发：
//接收缓冲区
int nRecvBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_RCVBUF,(const char*)&nRecvBuf,sizeof(int));
//发送缓冲区
int nSendBuf=32*1024;//设置为32K
setsockopt(s,SOL_SOCKET,SO_SNDBUF,(const char*)&nSendBuf,sizeof(int));

5. 如果在发送数据的时，希望不经历由系统缓冲区到socket缓冲区的拷贝而影响
程序的性能：
int nZero=0;
setsockopt(socket，SOL_S0CKET,SO_SNDBUF，(char *)&nZero,sizeof(nZero));

6.同上在recv()完成上述功能(默认情况是将socket缓冲区的内容拷贝到系统缓冲区)：
int nZero=0;
setsockopt(socket，SOL_S0CKET,SO_RCVBUF，(char *)&nZero,sizeof(int));

7.一般在发送UDP数据报的时候，希望该socket发送的数据具有广播特性：
BOOL bBroadcast=TRUE;
setsockopt(s,SOL_SOCKET,SO_BROADCAST,(const char*)&bBroadcast,sizeof(BOOL));

8.在client连接服务器过程中，如果处于非阻塞模式下的socket在connect()的过程中可
以设置connect()延时,直到accpet()被呼叫(本函数设置只有在非阻塞的过程中有显著的
作用，在阻塞的函数调用中作用不大)
BOOL bConditionalAccept=TRUE;
setsockopt(s,SOL_SOCKET,SO_CONDITIONAL_ACCEPT,(const char*)&bConditionalAccept,sizeof(BOOL));

9.如果在发送数据的过程中(send()没有完成，还有数据没发送)而调用了closesocket(),以前我们
一般采取的措施是"从容关闭"shutdown(s,SD_BOTH),但是数据是肯定丢失了，如何设置让程序满足具体
应用的要求(即让没发完的数据发送出去后在关闭socket)？
struct linger {
u_short l_onoff;
u_short l_linger;
};
linger m_sLinger;
m_sLinger.l_onoff=1;//(在closesocket()调用,但是还有数据没发送完毕的时候容许逗留)
// 如果m_sLinger.l_onoff=0;则功能和2.)作用相同;
m_sLinger.l_linger=5;//(容许逗留的时间为5秒)

setsockopt(s,SOL_SOCKET,SO_LINGER,(const char*)&m_sLinger,sizeof(linger));

阅读全文(461) | 评论:0 | 复制链接

placement new(2012-1-5 10:36:00)

有关placement new
                                             hzh512
&#61656;    placement new的含义
placement new 是重载operator new 的一个标准、全局的版本，它不能够被自定义的版本代替（不像普通版本的operator new 和 operator delete能够被替换）。

void *operator new( size_t, void *p ) throw()     { return p; }

placement new的执行忽略了size_t参数，只返还第二个参数。其结果是允许用户把一个对象放到一个特定的地方，达到调用构造函数的效果。

和其他普通的new不同的是，它在括号里多了另外一个参数。比如：
Widget * p = new Widget; - - - - - - - - - //ordinary new 
pi = new (ptr) int; pi = new (ptr) int;     //placement new

括号里的参数ptr是一个指针，它指向一个内存缓冲器，placement new将在这个缓冲器上分配一个对象。Placement new的返回值是这个被构造对象的地址(比如括号中的传递参数)。placement new主要适用于：在对时间要求非常高的应用程序中，因为这些程序分配的时间是确定的；长时间运行而不被打断的程序；以及执行一个垃圾收集器 (garbage collector)。
&#61656;    new 、operator new 和 placement new 区别
new ：不能被重载，其行为总是一致的。它先调用operator new分配内存，然后调用构造函数初始化那段内存。

operator new：要实现不同的内存分配行为，应该重载operator new，而不是new。

delete和operator delete类似。

placement new：只是operator new重载的一个版本。它并不分配内存，只是返回指向已经分配好的某段内存的一个指针。因此不能删除它，但需要调用对象的析构函数。
&#61656;    new 操作符的执行过程
1. 调用operator new分配内存 ；
2. 调用构造函数生成类对象；
3. 返回相应指针。

operator new就像operator+一样，是可以重载的。如果类中没有重载operator new，那么调用的就是全局的::operator new来完成堆的分配。同理，operator new[]、operator delete、operator delete[]也是可以重载的，其实operator new也是operator new的一个重载的版本，只是很少用而已。如果你想在已经分配的内存中创建一个对象，使用new时行不通的。也就是说placement new允许你在一个已经分配好的内存中（栈或者堆中）构造一个新的对象。原型中void*p实际上就是指向一个已经分配好的内存缓冲区的的首地址。
&#61656;    Placement new 存在的理由
1.用Placement new 解决buffer的问题

问题描述：用new分配的数组缓冲时，由于调用了默认构造函数，因此执行效率上不佳。若没有默认构造函数则会发生编译时错误。如果你想在预分配的内存上创建对象，用缺省的new操作符是行不通的。要解决这个问题，你可以用placement new构造。它允许你构造一个新对象到预分配的内存上。

2.增大时空效率的问题
 
使用new操作符分配内存需要在堆中查找足够大的剩余空间，显然这个操作速度是很慢的，而且有可能出现无法分配内存的异常（空间不够）。 
placement new就可以解决这个问题。我们构造对象都是在一个预先准备好了的内存缓冲区中进行，不需要查找内存，内存分配的时间是常数；而且不会出现在程序运行中途出现内存不足的异常。所以，placement new非常适合那些对时间要求比较高，长时间运行不希望被打断的应用程序。
&#61656;    使用步骤
在很多情况下，placement new的使用方法和其他普通的new有所不同。这里提供了它的使用步骤。

第一步  缓存提前分配
有三种方式：
1.为了保证通过placement new使用的缓存区的memory alignmen(内存队列)正确准备，使用普通的new来分配它：在堆上进行分配

class Task ;

char * buff = new [sizeof(Task)]; //分配内存

(请注意auto或者static内存并非都正确地为每一个对象类型排列，所以，你将不能以placement new使用它们。)

2.在栈上进行分配

class Task ;
char buf[N*sizeof(Task)]; //分配内存

3.还有一种方式，就是直接通过地址来使用。(必须是有意义的地址)

void* buf = reinterpret_cast<void*> (0xF00F);

第二步：对象的分配

在刚才已分配的缓存区调用placement new来构造一个对象。

Task *ptask = new (buf) Task
第三步：使用
按照普通方式使用分配的对象：

ptask->memberfunction();

ptask-> member;

//...

第四步：对象的析构

一旦你使用完这个对象，你必须调用它的析构函数来毁灭它。按照下面的方式调用析构函数：

ptask->~Task(); //调用外在的析构函数

第五步：释放

你可以反复利用缓存并给它分配一个新的对象（重复步骤2，3，4）如果你不打算再次使用这个缓存，你可以象这样释放它：

delete [] buf;

跳过任何步骤就可能导致运行时间的崩溃，内存泄露，以及其它的意想不到的情况。如果你确实需要使用placement new，请认真遵循以上的步骤。

转载请注明：hzh512

 

 

本人述: 一定要显示调用析构函数, 要不然会有内存泄漏, 导致虚拟内存不断增加

阅读全文(254) | 评论:0 | 复制链接

bat命令(2011-12-13 14:35:00)

在Unix环境下，命令行或者shell中sleep和kill是常见的动作，在Windows的.bat文件中处理类似的任务就不那么直接了，备忘如下：

[sleep]
ping 127.0.0.1 -n 需要的秒数+1 -w 1000 > nul

[kill]
taskkill /f /im "进程名(如notepad.exe)"
taskkill /f /fi "WINDOWTITLE eq notepad*"

其中/f表示强制，/im表示image镜像名(可执行文件名)，/fi表示filter，后面跟表达式，比如这里的"窗体标题等于notepad*"，支持wildcast通配符。

阅读全文(268) | 评论:0 | 复制链接

CentOS SVN服务器的安装与配置(转)(2011-12-12 22:03:00)

阅读全文(527) | 评论:0 | 复制链接

C/C++ 宏带来的奇技淫巧(转)(2011-12-5 19:04:00)

众多C++书籍都忠告我们C语言宏是万恶之首，但事情总不如我们想象的那么坏，就如同goto一样。宏有
一个很大的作用，就是自动为我们产生代码。如果说模板可以为我们产生各种型别的代码(型别替换)，
那么宏其实可以为我们在符号上产生新的代码(即符号替换、增加)。

关于宏的一些语法问题，可以在google上找到。相信我，你对于宏的了解绝对没你想象的那么多。如果你
还不知道#和##，也不知道prescan，那么你肯定对宏的了解不够。

我稍微讲解下宏的一些语法问题(说语法问题似乎不妥，macro只与preprocessor有关，跟语义分析又无关)：

1. 宏可以像函数一样被定义，例如：
   #define min(x,y) (x<y?x:y) //事实上这个宏存在BUG
   但是在实际使用时，只有当写上min()，必须加括号，min才会被作为宏展开，否则不做任何处理。
  
2. 如果宏需要参数，你可以不传，编译器会给你警告(宏参数不够)，但是这会导致错误。如C++书籍中所描
   述的，编译器(预处理器)对宏的语法检查不够，所以更多的检查性工作得你自己来做。

3. 很多程序员不知道的#和##
   #符号把一个符号直接转换为字符串，例如：
   #define STRING(x) #x
   const char *str = STRING( test_string ); str的内容就是"test_string"，也就是说#会把其后的符号
   直接加上双引号。
   ##符号会连接两个符号，从而产生新的符号(词法层次)，例如：
   #define SIGN( x ) INT_##x
   int SIGN( 1 ); 宏被展开后将成为：int INT_1;

4. 变参宏，这个比较酷，它使得你可以定义类似的宏：
   #define LOG( format, ... ) printf( format, __VA_ARGS__ )
   LOG( "%s %d", str, count );
   __VA_ARGS__是系统预定义宏，被自动替换为参数列表。

5. 当一个宏自己调用自己时，会发生什么？例如：
   #define TEST( x ) ( x + TEST( x ) )
   TEST( 1 ); 会发生什么？为了防止无限制递归展开，语法规定，当一个宏遇到自己时，就停止展开，也就是
   说，当对TEST( 1 )进行展开时，展开过程中又发现了一个TEST，那么就将这个TEST当作一般的符号。TEST(1)
   最终被展开为：1 + TEST( 1) 。

6. 宏参数的prescan，
   当一个宏参数被放进宏体时，这个宏参数会首先被全部展开(有例外，见下文)。当展开后的宏参数被放进宏体时，
   预处理器对新展开的宏体进行第二次扫描，并继续展开。例如：
   #define PARAM( x ) x
   #define ADDPARAM( x ) INT_##x
   PARAM( ADDPARAM( 1 ) );
   因为ADDPARAM( 1 ) 是作为PARAM的宏参数，所以先将ADDPARAM( 1 )展开为INT_1，然后再将INT_1放进PARAM。
  
   例外情况是，如果PARAM宏里对宏参数使用了#或##，那么宏参数不会被展开：
   #define PARAM( x ) #x
   #define ADDPARAM( x ) INT_##x
   PARAM( ADDPARAM( 1 ) ); 将被展开为"ADDPARAM( 1 )"。

   使用这么一个规则，可以创建一个很有趣的技术：打印出一个宏被展开后的样子，这样可以方便你分析代码：
   #define TO_STRING( x ) TO_STRING1( x )
   #define TO_STRING1( x ) #x
   TO_STRING首先会将x全部展开(如果x也是一个宏的话)，然后再传给TO_STRING1转换为字符串，现在你可以这样：
   const char *str = TO_STRING( PARAM( ADDPARAM( 1 ) ) );去一探PARAM展开后的样子。

7. 一个很重要的补充：就像我在第一点说的那样，如果一个像函数的宏在使用时没有出现括号，那么预处理器只是
   将这个宏作为一般的符号处理(那就是不处理)。

我们来见识一下宏是如何帮助我们自动产生代码的。如我所说，宏是在符号层次产生代码。我在分析Boost.Function
模块时，因为它使用了大量的宏(宏嵌套，再嵌套)，导致我压根没看明白代码。后来发现了一个小型的模板库ttl，说的
是开发一些小型组件去取代部分Boost(这是一个好理由，因为Boost确实太大)。同样，这个库也包含了一个function库。
这里的function也就是我之前提到的functor。ttl.function库里为了自动产生很多类似的代码，使用了一个宏：

#define TTL_FUNC_BUILD_FUNCTOR_CALLER(n) 
 template< typename R, TTL_TPARAMS(n) >
 struct functor_caller_base##n
        ///...
该宏的最终目的是：通过类似于TTL_FUNC_BUILD_FUNCTOR_CALLER(1)的调用方式，自动产生很多functor_caller_base模板：
template <typename R, typename T1> struct functor_caller_base1
template <typename R, typename T1, typename T2> struct functor_caller_base2
template <typename R, typename T1, typename T2, typename T3> struct functor_caller_base3
///...
那么，核心部分在于TTL_TPARAMS(n)这个宏，可以看出这个宏最终产生的是：
typename T1
typename T1, typename T2
typename T1, typename T2, typename T3
///...
我们不妨分析TTL_TPARAMS(n)的整个过程。分析宏主要把握我以上提到的一些要点即可。以下过程我建议你翻着ttl的代码，
相关代码文件：function.hpp, macro_params.hpp, macro_repeat.hpp, macro_misc.hpp, macro_counter.hpp。

so, here we go

分析过程，逐层分析，逐层展开，例如TTL_TPARAMS(1)：

#define TTL_TPARAMS(n) TTL_TPARAMSX(n,T) 
=> TTL_TPARAMSX( 1, T )
#define TTL_TPARAMSX(n,t) TTL_REPEAT(n, TTL_TPARAM, TTL_TPARAM_END, t)
=> TTL_REPEAT( 1, TTL_TPARAM, TTL_TPARAM_END, T )
#define TTL_TPARAM(n,t) typename t##n,
#define TTL_TPARAM_END(n,t) typename t##n
#define TTL_REPEAT(n, m, l, p) TTL_APPEND(TTL_REPEAT_, TTL_DEC(n))(m,l,p) TTL_APPEND(TTL_LAST_REPEAT_,n)(l,p)
注意，TTL_TPARAM, TTL_TPARAM_END虽然也是两个宏，他们被作为TTL_REPEAT宏的参数，按照prescan规则，似乎应该先将
这两个宏展开再传给TTL_REPEAT。但是，如同我在前面重点提到的，这两个宏是function-like macro，使用时需要加括号，
如果没加括号，则不当作宏处理。因此，展开TTL_REPEAT时，应该为：
=> TTL_APPEND( TTL_REPEAT_, TTL_DEC(1))(TTL_TPARAM,TTL_TPARAM_END,T) TTL_APPEND( TTL_LAST_REPEAT_,1)(
TTL_TPARAM_END,T)
这个宏体看起来很复杂，仔细分析下，可以分为两部分：
TTL_APPEND( TTL_REPEAT_, TTL_DEC(1))(TTL_TPARAM,TTL_TPARAM_END,T)以及
TTL_APPEND( TTL_LAST_REPEAT_,1)(TTL_TPARAM_END,T)
先分析第一部分：
#define TTL_APPEND( x, y ) TTL_APPEND1(x,y) //先展开x,y再将x,y连接起来
#define TTL_APPEND1( x, y ) x ## y
#define TTL_DEC(n) TTL_APPEND(TTL_CNTDEC_, n)
根据先展开参数的原则，会先展开TTL_DEC(1)
=> TTL_APPEND(TTL_CNTDEC_,1) => TTL_CNTDEC_1
#define TTL_CNTDEC_1 0  注意，TTL_CNTDEC_不是宏，TTL_CNTDEC_1是一个宏。
=> 0 ， 也就是说，TTL_DEC(1)最终被展开为0。回到TTL_APPEND部分：
=> TTL_REPEAT_0 (TTL_TPARAM,TTL_TPARAM_END,T)
#define TTL_REPEAT_0(m,l,p)
TTL_REPEAT_0这个宏为空，那么，上面说的第一部分被忽略，现在只剩下第二部分：
TTL_APPEND( TTL_LAST_REPEAT_,1)(TTL_TPARAM_END,T)
=> TTL_LAST_REPEAT_1 (TTL_TPARAM_END,T) // TTL_APPEND将TTL_LAST_REPEAT_和1合并起来
#define TTL_LAST_REPEAT_1(m,p) m(1,p)
=> TTL_TPARAM_END( 1, T )
#define TTL_TPARAM_END(n,t) typename t##n
=> typename T1  展开完毕。

虽然我们分析出来了，但是这其实并不是我们想要的。我们应该从那些宏里去获取作者关于宏的编程思想。很好地使用宏
看上去似乎是一些偏门的奇技淫巧，但是他确实可以让我们编码更自动化。

参考资料：
macro语法: http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/cpp/Macros.html
ttl(tiny template library) : http://tinytl.sourceforge.net/

来自：http://www.cppblog.com/kevinlynx/archive/2008/03/19/44828.html

阅读全文(417) | 评论:1 | 复制链接

C++特化模板静态成员变量初始化(2011-12-5 15:20:00)

template<typename T>
struct TFSS
{
    static const char* FMT;
};
template<typename T>
const char* TFSS<T>::FMT = "%s";

template<>
struct TFSS<char>
{
    static const char* FMT;
};
template<>
const char* TFSS<char>::FMT = "%hu";

template<>
struct TFSS<unsigned char>
{
    static const char* FMT;
};
template<>
const char* TFSS<unsigned char>::FMT = "%hd";

 

代码编译出错

error C2998: “const char *TFSS<char>::FMT”: 不能是模板定义
error C2998: “const char *TFSS<unsigned char>::FMT”: 不能是模板定义

修改成如下代码

template<typename T>
struct TFSS
{
    static const char* FMT;
};
template<typename T>
const char* TFSS<T>::FMT = "%s";

template<>
struct TFSS<char>
{
    static const char* FMT;
};
const char* TFSS<char>::FMT = "%hu";

template<>
struct TFSS<unsigned char>
{
    static const char* FMT;
};
const char* TFSS<unsigned char>::FMT = "%hd";

阅读全文(472) | 评论:0 | 复制链接