CppExplore

@田伯光
多個(gè)進(jìn)程指向同一個(gè)文件的話，的確都可以寫進(jìn)去。至于是不是穩(wěn)定就不清楚了，呵呵，我一直是單進(jìn)程多線程下使用，偶爾忘記程序已經(jīng)啟動，第二次啟動，同樣會把log寫進(jìn)文件。
你多測試下吧。
log4cplus的配置文件的配置方式網(wǎng)上不少，或者你留個(gè)郵箱，我發(fā)給你。

@mono，給你個(gè)可以編譯通過的宏，不知道你是win下還linux下，下面的宏都可以，另外流式的log不容易和printf、ace等對應(yīng)，也看個(gè)人喜好，我是認(rèn)為printf的方式更容易格式化輸出。
#define USE_LOG4CPLUS
#ifdef USE_LOG4CPLUS
#include <log4cplus/configurator.h>
#include <string>
static log4cplus::Logger logger= log4cplus::Logger::getInstance("Log");
static void init_log(const std::string & path)
{
log4cplus::PropertyConfigurator::doConfigure(path);
}
#define XLOG_ALL log4cplus::TRACE_LOG_LEVEL
#define XLOG_TRACE log4cplus::TRACE_LOG_LEVEL
#define XLOG_DEBUG log4cplus::DEBUG_LOG_LEVEL
#define XLOG_INFO log4cplus::INFO_LOG_LEVEL
#define XLOG_NOTICE log4cplus::INFO_LOG_LEVEL
#define XLOG_WARNING log4cplus::WARN_LOG_LEVEL
#define XLOG_ERROR log4cplus::ERROR_LOG_LEVEL
#define XLOG_CRITICAL log4cplus::FATAL_LOG_LEVEL

#ifdef WIN32
#if (_MSC_VER < 1500)
#define vsnprintf _vsnprintf
#endif
void inline win_log( int l, const char *format, ... )
{
if(logger.isEnabledFor(l)) {
schar buf[2046]={0};
va_list list;
va_start( list, format );
vsnprintf( buf, (size_t)2045,format, list );
va_end( list );
logger.forcedLog(l, buf, __FILE__, __LINE__);
}
}
#define X_LOG win_log
#else
#define X_LOG(l, ...) \
do { \
if(logger.isEnabledFor(l)) { \
char __buf__internal__[2046]={0}; \
snprintf(__buf__internal__,2045,__VA_ARGS__); \
logger.forcedLog(l, __buf__internal__, __FILE__, __LINE__); \
} \
} while(0)
#endif

@guosha
沒有用過。
log是個(gè)小功能，封裝下能做到透明使用基本就可以了。log4c依賴apr庫，如果你的主體程序不是在apr上構(gòu)建的話，引入log4c不太舒服，呵呵。

。。。。。。。。。。。
路過。。。。。。。。。
。。。。。。。。。。。

@mono
#define USE_LOG4CPLUS
之后就編譯正確了吧，或者你把define USE_ACE_LOG那段去掉，可以用printf調(diào)式。
你的需求是什么樣子的？我用于server端程序，在main函數(shù)開始，來句：
#ifdef USE_LOG4CPLUS
init_log("./log.properties");
#endif
之后就再就是正常的程序啟動了，起各個(gè)協(xié)議棧、線程。當(dāng)然log也都是打印在一個(gè)log文件里。
server端程序是一直運(yùn)行的，不會退出，也就不存在消亡的問題。

@true
業(yè)務(wù)線程也不見得是多線程實(shí)現(xiàn)，尤其是是處理有上下文關(guān)聯(lián)關(guān)系（比如，rtsp協(xié)議，發(fā)了setup，才能發(fā)play，發(fā)送teardown之后才結(jié)束，不同階段狀態(tài)是不同的，http是無狀態(tài)的協(xié)議就另說了）邏輯的業(yè)務(wù)線程 ，一般都是單線程。把握住系統(tǒng)瓶頸的所在，在關(guān)鍵業(yè)務(wù)瓶頸處加多線程。另外，如果真想實(shí)現(xiàn)你說的情況，可以綁定connection和上層業(yè)務(wù)線程，我覺得這不會有性能的提升，當(dāng)然也要看你的業(yè)務(wù)應(yīng)用場景。

@伐木鼎鼎
呵呵，沒那么嚴(yán)重，可以做丟包重傳機(jī)制，這樣第一次a發(fā)給b的包可能會被拒收，第一個(gè)b發(fā)給a的也可能被拒收，但后面的包就正常了。

@cui
呵呵，那是線程（二）中說的。
開始寫文章有不少錯(cuò)誤的認(rèn)識，后來對問題的看法再不停的調(diào)整，但舊有的文章中有的錯(cuò)誤說法一直沒有更正。這篇文章里的信號量就是一例。

@powervv
不錯(cuò)。二進(jìn)制包更多的是對字節(jié)序、字節(jié)對齊問題的深入。關(guān)鍵的地方還是struct結(jié)構(gòu)的準(zhǔn)確定義，包括大小端、字節(jié)對齊問題。幸好一般協(xié)議在定義的時(shí)候，都會注意字節(jié)對齊問題，不夠1字節(jié)也會加padding補(bǔ)充，呵呵。
除了字節(jié)補(bǔ)充完成外，一般也都會保證4字節(jié)對齊完成，因此文中舉例的3字節(jié)結(jié)構(gòu)體實(shí)際中是不存在的，即便是不要額外信息，協(xié)議也會在seq前規(guī)定1字節(jié)的padding補(bǔ)充滿4字節(jié)，在seq前補(bǔ)充也是為了避免設(shè)置pack(1)。
感謝補(bǔ)充！

@cui
多謝。最近看到了，這個(gè)是信號安全的系統(tǒng)調(diào)用。

@小魚
忘記說et下的fd要設(shè)置非阻塞，其實(shí)多路復(fù)用函數(shù)下的fd一般都是非阻塞模式。雖然要減少read的次數(shù)，即便是lt模式下，也不能數(shù)據(jù)少就不讀，呵呵。ET下數(shù)據(jù)沒讀完，這個(gè)fd就永遠(yuǎn)不會有事件上來了。et是邊緣觸發(fā)，就是從無數(shù)據(jù)到有數(shù)據(jù)這個(gè)變化點(diǎn)會觸發(fā)，lt是水平觸發(fā)，只要socket緩沖區(qū)有數(shù)據(jù)（當(dāng)?shù)统睂傩栽O(shè)置為1的時(shí)候，默認(rèn)也是1）就會觸發(fā)。

ET模式下fd可讀 就要一直讀到返回－1并且errno是EAGAIN(信號中斷產(chǎn)生的EINTR要繼續(xù))?？梢詍an epoll看到。

...............
首頁上，你上篇文章之前的文章就是有關(guān) 成員函數(shù)委托 的，兩篇文章緊挨著

@創(chuàng)
listen后 accept前加fork是常見的設(shè)計(jì)，在不使用多路復(fù)用函數(shù)的情況下
@luke
區(qū)別就是fork前生成fd ，會導(dǎo)致多個(gè)進(jìn)程在相同epoll上wait

想法不錯(cuò)，把a(bǔ)ccept前的多進(jìn)程用于多路復(fù)用函數(shù)，完美的方案，呵呵。
現(xiàn)實(shí)世界往往都不是那么完美。
還沒看到過select poll epoll類的應(yīng)用前面可以加fork做這種領(lǐng)導(dǎo)者模型的。想想也不太現(xiàn)實(shí)，即使可以多進(jìn)程select，那么一個(gè)被喚醒后，讀數(shù)據(jù)前，另一個(gè)也一定會被喚醒，這樣還是和單進(jìn)程一樣。

非常不錯(cuò)！
強(qiáng)大的消息映射、狀態(tài)機(jī)事件映射都要靠這個(gè)才能完美的解決成員函數(shù)的問題。

頂一下
前幾天我也剛寫了一個(gè)，用在線程消息的處理中，我的消息類型做數(shù)組下標(biāo)了，直接定位取處理函數(shù)，這都是無關(guān)緊要的細(xì)節(jié)。關(guān)鍵在ON_COMMAND宏的展現(xiàn)方式，我的處理線程消息，名字起做ON_MESSAGE
整體思路基本都是一樣的，呵呵。

@flw
好東西 非常感謝

來拜拜牛人！
太牛了?。。。。。。。。。。。。。。?/div>