CentOS下版本控制软件subversion的安装

烽驿2009开源实时通信平台 源码获取：http://fy2009.googlecode.com/svn/trunk/ fy2009-read-only

 

笔者在前面的博文中陆续介绍了本项目实现的若干基础服务，如：时间服务(http://blog.csdn.net/DreamFreeLancer/archive/2009/05/05/4150165.aspx, http://blog.csdn.net/DreamFreeLancer/archive/2009/05/05/4151871.aspx)，

日志服务(http://blog.csdn.net/DreamFreeLancer/archive/2009/06/07/4250289.aspx)，消息服务(http://blog.csdn.net/DreamFreeLancer/archive/2009/06/13/4266189.aspx)和异步IO服务

(http://blog.csdn.net/DreamFreeLancer/archive/2009/07/26/4381316.aspx)等。其中日志，消息和异步IO服务均用到所谓线程局部存储（TLS）。为方便在线程中使用这些基础服务，并尽可能保持线程概念在Windows和Linux间的可移

植性，本项目实现了thread_t，该类是个虚基类，不能直接实例化，自定义线程类需继承该类并重写其纯虚函数。

 

thread_t实现简要描述如下：
int32 start()－－创建操作系统线程，直至完成应用级初始化才返回，成功，返回零；否则，返回非零。

virtual void run()=0－－thread_t隐藏了操作系统的线程函数，应用层线程逻辑将被实现在该函数中。实现通常遵循以下模式：

线程初始化语句体
_unlock_start(); //完成应用级线程初始化后，需调用该保护函数以释放创建线程的start()调用，即start()将在该调用后返回创建线程。
应用逻辑语句体
线程退出清理语句体

 

若用户线程是个执行周期任务的“长寿”线程，则上述“应用逻辑语句体”通常是个while(true){...}样式的“死循环”。这时在循环体的适当位置应调用保护函数_is_stopping()检测是否有外部线程通过stop()调用向本线程发出终止请求，如果

_is_stopping()返回true, 应执行break语句跳出循环，并最终结束线程。另外，若while循环体中驱动的是heart_beat_it接口，则应在heart_beat()返回RET_HB_IDLE时或在周期性完成当前应用逻辑时调用保护函数_on_idle()，该函数尝试将Block在本线程缓冲区的日志送往写日志线程（如果Enable了Trace服务）或调用message proxy的heart_beat尝试接收发往本线程的消息（如果Enable了Message服务）或调用aio proxy的heart_beat尝试接收发往本线程的异步IO事件（如果Enable了AIO服务）。如果当前没任何日志等待送往写日志线程;

或没有任何消息被送到本线程;或没有任何异步IO事件被送到本线程，则_on_idle调用会被阻塞在内部一个event slot上直至指定超时，或前面任一事件发生。因此，当前无事可干的“长寿线程”可挂起在_on_idle上，既减小系统空转消耗，又避免sleep引起的响应不及时。

void stop(uint32 timeout)－－外部线程可通过调用该函数通知目标线程退出，目标线程应通过显式调用_is_stopping()感知该请求，并及时退出线程函数。stop在发出上述终止请求后，将等待一个超时时间，若在超时到达时，目标线程仍未退出，最初的实现在Windows和Linux下行为并不一致，在Linux上，原来通过调用pthread_cancel来终止线程，而在Windows下则调用TerminateThread直接结束线程。但两者都不完美，pthread_cancel向目标线程发出“取消请求”，当目标线程执行到所谓“取消点（Cancellation Point）”时，目标线程将退出。线程退出机制以抛出一个特殊异常的方式进行，该异常不能被用户的try...catch捕捉并终止，就是说用户程序中的catch(...)子句最后必需用一个“throw;”语句再抛出，否则，程序将出错（FATAL: exception not rethrown），这是一件很不幸的事，该特性会导致任何构成线程函数的代码中不能有不含"throw;"语句的catch(...)子句，这会导致本项目所有异常处理的宏不能用在线程函数中，这太不幸了，也不能被接受。经过权衡，最后放弃了整个线程Cancel机制（本来这也只是一种容错处理，良好设计的线程函数本来就不应该发生这种事），另外一个额外收获是保持了线程概念在Windows平台和Linux平台上的高度一致，当然，为此也取消了在Windows上线程无法法正常结束时对TerminateThread调用，反正该函数也不回收线程资源，调它何用？既然不能正常结束，那就随它“自生自灭”好了，从此“一刀两断”。总之，无论在Windows下还是Linux下，我们都应小心编写run函数实现，及时调用_is_stopping，发现来自其它线程的stop请求及时退出。
void enable_trace/disable_trace－－Enable/Disable本线程的日志服务。如需要从线程中写日志，应Enable日志服务;否则，可Disable，以适当减少线程对象开销。必需在start()前调用。
void enable_msg/disable_msg－－Enable/Disable本线程消息服务，如线程需要收/发消息，应Enable 消息服务。必需在start()前调用。
void enable_aio/disable_aio－－Enable/Disable本线程异步IO服务，如线程要用到异步IO（如异步Socket），应Enable异步IO操作。必需在start()前调用。 

 

注：Linux下标识一个线程用线程ID（Linux下的类型是pthread_t），pthread_create会产生该值，线程外可从此处得到该值，线程内部则可通过调用pthread_self得到指向自身的线程ID。值得注意的是出现在Linux高版本（如2.6）中的gettid和我们“顾名思义”的结果并不相同，它的含义更接近getpid而不是获取我们认为的线程ID，也就是说，同一进程中不同线程调用gettid通常返回相同的值，即进程ID。系统帮助说明了gettid和getpid什么情况下不同（用CLONE_THREAD调用clone时），但和我们通常的线程ID没有任何关系。总之， 从线程内部得到自身ID的正确方法是pthread_self而不是别的。

 

Windows下对应线程有两个系统对象，一个是线程句柄，一个是线程ID，有使简单问题复杂化的嫌疑。线程ID可在系统范围内唯一标识一个线程，和Linux下的类似概念作用相同。但Windows下很多线程函数却需要以线程句柄为参数。CreateThread直接返回的是线程句柄，但可通过一个参数返回线程ID，线程外可从此处得到线程句柄和线程ID。从线程内部获取线程ID可调用GetCurrentThreadId,但从线程内部获取线程句柄则得当心，GetCurrentThread貌似正确的选择，但其实该函数返回的是所谓的“伪句柄”，仅限于线程内使用，实际它的值在所有线程中都相同（XP上实测为0xfffffffe），也就是说它和CreateThread创建该线程时产生的句柄并不相等，对该“伪句柄”调用DuplicateHandle可生成真正的句柄，可在当前线程外使用，但使用者需负责用完后对其执行CloseHandle，“伪句柄”则从来不用Close。总之，在Windows下使用线程句柄，需小心区分是“真句柄”还是“伪句柄”，并弄清两者不同的适用场景。