• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆 - 6  文章 - 11  trackbacks - 0
            <2025年6月>
            25262728293031
            1234567
            891011121314
            15161718192021
            22232425262728
            293012345

            常用鏈接

            留言簿(1)

            隨筆檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            02 2011 檔案
            LuaVM Remote Debugger      摘要: 基于Lua 5.1實現的遠程調試器,腳本運行在服務端,客戶端登錄后可以遠程管理腳本,可以調試腳本,單步跟進、變量查看。
            界面基于wxWidgets實現,網絡通訊接口采用CORBA/TAO。  閱讀全文
            posted @ 2011-02-28 16:23 風雷九州 閱讀(1963) | 評論 (2)  編輯
            一個基于ACE的負載自適應萬能線程池實現      摘要: 在C++中要進行并發處理,不可避免要使用多線程,在傳統的教科書中,大家都是采用最原始的多線程技術,應用邏輯和線程并發策略緊密綁定。
            在一個典型的服務器程序中,客戶端的請求往往包含了很多不同的邏輯命令,如在一個線程處理函數中,需要根據客戶端的命令代碼處理不同的業務邏輯:

            int thrad_main(int cmd_id,char *data){
            switch(cmd_id)
            {
            case 1:
            ...
            break;
            case 2:
            ...
            break;
            }
            }

            如此這般,業務處理邏輯和線程邏輯緊密耦合,這是一種很“丑陋”的代碼。
            如何通過一種優雅的方法,分離并發邏輯和業務邏輯,通過通用的并發框架,業務邏輯設計者只需要關心自己的邏輯代碼,交給“線程池”去處理即可,而不需要去關心如何創建線程,等待線程結果這些瑣碎的“小事”?  閱讀全文
            posted @ 2011-02-28 15:46 風雷九州 閱讀(4273) | 評論 (3)  編輯
            一個簡單的PostgreSQL數據庫連接池實現      摘要:   平臺服務和腳本服務接口對后端PostgreSQL數據庫的使用目前采用短暫連接方式,造成多次調用服務時頻繁連接和斷開數據庫,效率很低。

              如果共享數據庫連接,則會造成多線程訪問數據庫時的事務沖突,故必須采用連接池來管理對數據庫的并發訪問,某一線程連接到數據庫使用完畢后,不斷開數據庫連接,而是把連接歸還給連接池。

              另一線程訪問數據庫時會首先向連接池申請已經存在的連接,如果連接池中沒有空閑連接,或者申請到得連接已經超時失效,再建立新的連接,使用完畢后同樣歸還到連接池。

              這樣連接池中的連接數會隨著線程壓力的增加逐漸增長,直到所有的線程同時工作,達到最多連接數。

              由于一個線程可能同時申請多個連接,故連接數可能會大于線程數。連接池在程序結束時銷毀全部連接,或者線程在申請到的某一連接失效時銷毀該連接。
              閱讀全文
            posted @ 2011-02-28 13:57 風雷九州 閱讀(5754) | 評論 (0)  編輯
            CORBA/TAO使用手記1 -- C/S架構網絡通信開發      摘要:   在C/S結構的C++網絡程序中,直接采用Socket API進行開發效率是很低的,所以大家發明了各種各樣的網絡框架,如Boost.Aiso和ACE,簡化了網絡通信開發的難度。
              但是這種基于數據包收發的模式還是不太方便,于是又出現了RPC、DCOM、CORBA等遠程接口調用的標準。客戶端只需要像調用本地函數一樣調用遠程接口,框架會自動處理數據包收發,請求和應答等底層細節。
              雖然現在Web技術的發展如火如荼,大有取代C/S架構應用之勢,但是,直接運行于操作系統平臺上的C++原生應用還是有它存在的意義,最主要的方面就是接近系統底層,對操作系統資源和底層設備的控制等,其他任何虛擬機上的中間語言是無法望其項背的。

              CORBA是一個為簡化跨平臺應用而提出的規范,它獨立于網絡協議、編程語言和軟硬件平臺,支持異構的分布式計算環境和不同編程語言間的對象重用。
              閱讀全文
            posted @ 2011-02-16 19:54 風雷九州 閱讀(3914) | 評論 (0)  編輯

            久久久久久国产精品无码下载| 久久精品国产99国产精品| 欧美精品乱码99久久蜜桃| 久久亚洲中文字幕精品一区| 亚洲色欲久久久综合网| www性久久久com| 久久综合久久美利坚合众国| www性久久久com| 国产精品久久久久a影院| 精品综合久久久久久97超人| 综合久久精品色| 91亚洲国产成人久久精品网址| 久久乐国产精品亚洲综合| 性做久久久久久久| 四虎影视久久久免费观看| 久久久久久综合一区中文字幕| 久久婷婷五月综合97色直播| 久久免费国产精品一区二区| 亚洲国产精品无码久久一区二区 | 国产成人久久精品一区二区三区| 亚洲成色WWW久久网站| 要久久爱在线免费观看| 99久久精品免费看国产免费| 久久午夜伦鲁片免费无码| 久久久久人妻一区二区三区| 久久久久久久综合综合狠狠| 99久久99久久精品国产| 久久精品aⅴ无码中文字字幕不卡 久久精品aⅴ无码中文字字幕重口 | 久久99精品国产自在现线小黄鸭 | 国产亚洲婷婷香蕉久久精品 | 久久国产精品一区| 久久久久久狠狠丁香| 国产精品久久久久影视不卡| 无遮挡粉嫩小泬久久久久久久 | 国产精品免费福利久久| 久久精品国产亚洲av水果派| 久久这里只有精品18| 久久精品人成免费| 久久青草国产精品一区| 精品久久久久久国产| 久久夜色tv网站|