• <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年8月>
            272829303112
            3456789
            10111213141516
            17181920212223
            24252627282930
            31123456

            常用鏈接

            留言簿(1)

            隨筆檔案

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            02 2011 檔案
            LuaVM Remote Debugger      摘要: 基于Lua 5.1實現的遠程調試器,腳本運行在服務端,客戶端登錄后可以遠程管理腳本,可以調試腳本,單步跟進、變量查看。
            界面基于wxWidgets實現,網絡通訊接口采用CORBA/TAO。  閱讀全文
            posted @ 2011-02-28 16:23 風雷九州 閱讀(1975) | 評論 (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 風雷九州 閱讀(4279) | 評論 (3)  編輯
            一個簡單的PostgreSQL數據庫連接池實現      摘要:   平臺服務和腳本服務接口對后端PostgreSQL數據庫的使用目前采用短暫連接方式,造成多次調用服務時頻繁連接和斷開數據庫,效率很低。

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

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

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

              由于一個線程可能同時申請多個連接,故連接數可能會大于線程數。連接池在程序結束時銷毀全部連接,或者線程在申請到的某一連接失效時銷毀該連接。
              閱讀全文
            posted @ 2011-02-28 13:57 風雷九州 閱讀(5767) | 評論 (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 風雷九州 閱讀(3927) | 評論 (0)  編輯

            欧美色综合久久久久久| 久久久久久国产精品美女| 国内高清久久久久久| 青青青国产精品国产精品久久久久 | 国产精品久久久久a影院| 性欧美大战久久久久久久| 三级三级久久三级久久| 亚洲国产一成人久久精品| 久久精品国产只有精品2020| 久久久久亚洲AV无码专区网站| 亚洲精品综合久久| 亚洲嫩草影院久久精品| 狠狠久久综合伊人不卡| 影音先锋女人AV鲁色资源网久久| 久久免费视频观看| 色婷婷综合久久久久中文| 亚洲国产精品综合久久网络| 久久青草国产精品一区| 亚洲午夜久久久影院伊人| 久久久久99精品成人片| 国产精品久久久久久搜索| 无码超乳爆乳中文字幕久久| 欧美亚洲国产精品久久久久| 久久国产成人| 日本免费一区二区久久人人澡| 久久人妻无码中文字幕| 一级女性全黄久久生活片免费| 久久精品人人做人人爽97 | 无码人妻久久一区二区三区| 久久久久久无码国产精品中文字幕| 国产精品99久久99久久久| 日本道色综合久久影院| 婷婷综合久久中文字幕蜜桃三电影| 香蕉久久久久久狠狠色| 无码人妻少妇久久中文字幕| 精品久久人人妻人人做精品| 伊人丁香狠狠色综合久久| 99久久国产亚洲高清观看2024| 99久久精品国产一区二区蜜芽| 日韩精品国产自在久久现线拍| 青青青青久久精品国产|