• <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)  編輯

            久久人爽人人爽人人片AV| 亚洲精品乱码久久久久久蜜桃不卡| 亚洲国产精品无码久久98| 久久久久久九九99精品| 办公室久久精品| 婷婷久久精品国产| 国内精品伊人久久久久av一坑| 久久精品免费观看| 久久婷婷色综合一区二区| 看久久久久久a级毛片| 国产91久久综合| 欧美一区二区三区久久综| 国产激情久久久久影院老熟女免费 | 性做久久久久久久| 青青青青久久精品国产h| 人人妻久久人人澡人人爽人人精品| 99久久人妻无码精品系列| 久久无码一区二区三区少妇| 99久久er这里只有精品18| 久久亚洲av无码精品浪潮| 69国产成人综合久久精品| 久久亚洲熟女cc98cm| 久久久久久青草大香综合精品| 国产亚洲欧美成人久久片| 久久亚洲AV无码精品色午夜| 精品多毛少妇人妻AV免费久久| 亚洲国产另类久久久精品黑人| 欧美久久久久久精选9999| 国产午夜久久影院| 99精品久久精品| 亚洲AV日韩精品久久久久 | 中文字幕久久精品无码| 久久国产精品一区| 久久精品成人免费观看97| 伊人久久免费视频| 一本色道久久88加勒比—综合| 亚洲av日韩精品久久久久久a| 久久国产欧美日韩精品| 国产色综合久久无码有码| 久久精品国产久精国产一老狼| 人妻无码精品久久亚瑟影视|