• <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>

            那誰的技術(shù)博客

            感興趣領(lǐng)域:高性能服務(wù)器編程,存儲,算法,Linux內(nèi)核
            隨筆 - 210, 文章 - 0, 評論 - 1183, 引用 - 0
            數(shù)據(jù)加載中……

            這是tokyo cabinet的一個BUG么

            最近在研讀tokyo cabinet的代碼,但是發(fā)現(xiàn)一個問題。
            目前在跟進的是使用hash table實現(xiàn)的數(shù)據(jù)庫文件,在項目的examples目錄下面有一些作者寫的demo文件演示如何使用的。我使用這里的tchdbex.c文件跟蹤代碼的運行情況,不過在里面加入了下面兩行代碼:
            /* store records */
              
            if(!tchdbput2(hdb, "foo""hop"||
                 
            !tchdbput2(hdb, "bar""step"||
                 
            !tchdbput2(hdb, "baz""jump")){
                ecode 
            = tchdbecode(hdb);
                fprintf(stderr, 
            "put error: %s\n", tchdberrmsg(ecode));
              }

            +  tchdbout2(hdb, "foo");
            +  tchdbput2(hdb, "foo""hop");

            (代碼前面加上+號的是我加上的兩行代碼)

            可以看到,我在加入了記錄(“foo”, “hop”)之后,對它進行了刪除操作,在這之后緊跟著再次插入相同的記錄。
            tokyo cabinet的hash-table實現(xiàn)中,刪除一條記錄時會將塌存放到一個free pool類型的數(shù)組中,這里面保存了這條刪除記錄的大小和在文件中的偏移量。

            問題在于,在加入記錄時,記錄的大小是32byte,刪除記錄時理所當然的也是刪除一條大小為32byte的記錄了,但是呢,緊跟著再次插入同樣的記錄時,代碼中(tchdb.c):
            3417      rec.rsiz = HDBMAXHSIZ + ksiz + vsiz;
            3418      if(!tchdbfbpsearch(hdb, &re
            3417行算出這條新插入的記錄應該是38byte,于是走入下面的函數(shù)tchdbfbpsearch 查找能滿足這個大小的freepool,之前返回的freepool是32,于是這個查找失敗了,不得不重新分配空間來存放這個新的記錄,而不是復用已經(jīng)返回的空間---盡管前后兩次插入的數(shù)據(jù)大小是一樣的。
            其實,在上面的代碼中,第二次插入記錄的時候,查找可用的freepool失敗之后繼續(xù)往下走,最后真正插入到文件中的數(shù)據(jù)記錄大小還是32的。

            我給作者發(fā)去郵件,咨詢這個問題,作者的回答大意是說我描述的這個現(xiàn)象確實存在,不過是有一定的考慮在里面的,后期會進行一些改進。我沒有完全的把這部分代碼閱讀完畢,所以也就不好多說什么了,下面附上郵件內(nèi)容,做一個記錄,也為可能會發(fā)現(xiàn)這個問題的朋友提個醒吧。

            我使用的版本是1.4.19。
            chuang
             發(fā)送至 hirarin
                
            顯示詳細信息 
            15:10 (6 小時前)
                
            Hi, hirarin,recently, I 
            try to read and trace the tokyocabinet source.
            when I use the examples
            /tchdbex.c to trace hash-table, I find a problem.

            In the file tchdbex.c, I add two lines:
              
            /* store records */
              
            if(!tchdbput2(hdb, "foo""hop"||
                 
            !tchdbput2(hdb, "bar""step"||
                 
            !tchdbput2(hdb, "baz""jump")){
                ecode 
            = tchdbecode(hdb);
                fprintf(stderr, 
            "put error: %s\n", tchdberrmsg(ecode));
              }

            +  tchdbout2(hdb, "foo");
            +  tchdbput2(hdb, "foo""hop");

            so, you can see that after insert key 
            "foo","bar" and "baz", I try to remove the record with the key "foo", and then insert record ("foo","hop") again.

            But, when i use gdb to trace the program, i find that, when i first insert the record (
            "foo""hop"), the record size is 32.
            and then, when i remove the record (
            "foo""hop"), the record size is 32, it is ok, then a free block with size 32 is inserted into the free block arrays.
            But, when I insert record (
            "foo""hop") once again, in the file tchdb.c:3417:
            3417      rec.rsiz = HDBMAXHSIZ + ksiz + vsiz;
            then the record size 
            is 38
            and then the next line it tries to find a free block fix to 
            this size, but there is only free block with size 32, so it is falied to find a free block.

            I mean that, 
            if I remove the record ("foo""hop") and then try to insert it again, seems that it should use the free block with size 32.Otherwise, there will be missing retrieval of the free block.

            So, 
            is it a bug??

            BTW: the version 
            is 1.4.19
             
            |
            Mikio Hirabayashi
             發(fā)送至 我
                
            顯示詳細信息 
            16:37 (5 小時前)
                
            Hi,

            Thanks 
            for the report.
            It
            's not a bug but on purpose.
            The header size is not calcurated at the line, I estimate it the
            maximum size 
            in theory.
            However, I hit on an idia thanks to you.  I
            'll change the logic to
            reduce the file size.

            Regards.



            posted on 2009-12-03 22:09 那誰 閱讀(4876) 評論(0)  編輯 收藏 引用 所屬分類: tokyo cabinet

            66精品综合久久久久久久| 久久天天躁狠狠躁夜夜2020老熟妇 | 精品视频久久久久| 人妻无码久久一区二区三区免费 | 亚洲国产精品无码久久久不卡| 久久久久久久久久久久久久| 国内精品久久久久影院一蜜桃| 99久久人人爽亚洲精品美女| 久久综合成人网| 国产一久久香蕉国产线看观看| 99久久亚洲综合精品成人| 午夜精品久久久久久影视777| 亚洲国产精品久久久天堂 | 久久人人妻人人爽人人爽| 亚洲一区中文字幕久久| 久久久午夜精品福利内容| 久久99国产精品久久久| 国产一区二区久久久| 精品无码久久久久久久久久| 色婷婷综合久久久中文字幕| 蜜桃麻豆www久久国产精品| 2020久久精品国产免费| 久久福利资源国产精品999| 久久中文字幕一区二区| 午夜人妻久久久久久久久| 人妻无码久久精品| 久久久精品波多野结衣| 久久免费小视频| 精品免费久久久久久久| 人妻无码αv中文字幕久久| 欧美黑人激情性久久| 久久久91人妻无码精品蜜桃HD| 久久久久四虎国产精品| 久久精品国产只有精品2020| 久久99久久99小草精品免视看| 久久精品九九亚洲精品| 久久综合给久久狠狠97色 | 蜜臀av性久久久久蜜臀aⅴ麻豆| 中文字幕无码av激情不卡久久| 久久这里有精品视频| 性做久久久久久久久久久|