• <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ù)器編程,存儲(chǔ),算法,Linux內(nèi)核
            隨筆 - 210, 文章 - 0, 評(píng)論 - 1183, 引用 - 0
            數(shù)據(jù)加載中……

            這是tokyo cabinet的一個(gè)BUG么

            最近在研讀tokyo cabinet的代碼,但是發(fā)現(xiàn)一個(gè)問題。
            目前在跟進(jìn)的是使用hash table實(shí)現(xiàn)的數(shù)據(jù)庫文件,在項(xiàng)目的examples目錄下面有一些作者寫的demo文件演示如何使用的。我使用這里的tchdbex.c文件跟蹤代碼的運(yùn)行情況,不過在里面加入了下面兩行代碼:
            /* 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");

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

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

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

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

            我使用的版本是1.4.19。
            chuang
             發(fā)送至 hirarin
                
            顯示詳細(xì)信息 
            15:10 (6 小時(shí)前)
                
            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ā)送至 我
                
            顯示詳細(xì)信息 
            16:37 (5 小時(shí)前)
                
            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 那誰 閱讀(4872) 評(píng)論(0)  編輯 收藏 引用 所屬分類: tokyo cabinet

            国产精品久久久亚洲| 久久国产福利免费| 国产精品久久久久aaaa| 久久久久亚洲av毛片大| 国产免费久久精品99re丫y| 色婷婷综合久久久中文字幕| 品成人欧美大片久久国产欧美| 久久久久亚洲国产| 久久er国产精品免费观看8| 97精品国产97久久久久久免费| 久久99精品久久久久久秒播| 久久99久久99精品免视看动漫| 久久www免费人成精品香蕉| 久久精品国产亚洲精品2020| 亚洲精品乱码久久久久66| 色欲综合久久躁天天躁| 国产午夜久久影院| 三上悠亚久久精品| 久久er99热精品一区二区| 亚洲一区精品伊人久久伊人| 99久久99久久精品国产片| 国产精品免费看久久久| 精品无码久久久久国产动漫3d | 久久精品中文闷骚内射| 亚洲а∨天堂久久精品9966| 大美女久久久久久j久久| 99久久国产综合精品成人影院| 青青青国产成人久久111网站| 99久久人妻无码精品系列蜜桃| 婷婷久久久亚洲欧洲日产国码AV| 久久AV高潮AV无码AV| 久久91精品国产91| 国产免费福利体检区久久| 日本免费一区二区久久人人澡| 国产成人无码精品久久久久免费 | 久久人人爽人人爽人人av东京热| 久久久久久久97| 亚洲va久久久久| 国产A三级久久精品| 久久久久亚洲AV无码观看| 97久久国产亚洲精品超碰热 |