3c/1b30b5ca2ce30b8f46d632d4879703db2b9d01

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 438A2431FBF;\r
   6         Mon, 23 Nov 2009 18:57:49 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id iA4VAJlEEGUF; Mon, 23 Nov 2009 18:57:48 -0800 (PST)\r
  11 Received: from cworth.org (localhost [127.0.0.1])\r
  12         by olra.theworths.org (Postfix) with ESMTP id 4B572431FAE;\r
  13         Mon, 23 Nov 2009 18:57:46 -0800 (PST)\r
  14 From: Carl Worth <cworth@cworth.org>\r
  15 To: djcb@djcbsoftware.nl\r
  16 In-Reply-To: <87pr79yaz1.wl%djcb@djcbsoftware.nl>\r
  17 References: <87aayggsjp.wl%djcb@djcbsoftware.nl>\r
  18         <87iqd43wot.fsf@yoom.home.cworth.org>\r
  19         <87skc6n3yp.wl%djcb@djcbsoftware.nl>\r
  20         <877htifa0e.fsf@yoom.home.cworth.org>\r
  21         <87pr79yaz1.wl%djcb@djcbsoftware.nl>\r
  22 Date: Mon, 23 Nov 2009 18:57:32 -0800\r
  23 Message-ID: <87k4xg634z.fsf@yoom.home.cworth.org>\r
  24 MIME-Version: 1.0\r
  25 Content-Type: text/plain; charset=us-ascii\r
  26 Cc: "notmuch@notmuchmail.org" <notmuch@notmuchmail.org>\r
  27 Subject: Re: [notmuch] interesting project!\r
  28 X-BeenThere: notmuch@notmuchmail.org\r
  29 X-Mailman-Version: 2.1.12\r
  30 Precedence: list\r
  31 List-Id: "Use and development of the notmuch mail system."\r
  32         <notmuch.notmuchmail.org>\r
  33 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  34         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  35 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  36 List-Post: <mailto:notmuch@notmuchmail.org>\r
  37 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  38 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  39         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  40 X-List-Received-Date: Tue, 24 Nov 2009 02:57:49 -0000\r
  41 \r
  42 On Mon, 23 Nov 2009 09:08:34 +0200, Dirk-Jan C. Binnema <djcb.bulk@gmail.com> wrote:\r
  43 > Well, the counter point to the OOM-problems is that is that in many programs,\r
  44 > the 'malloc returns NULL'-case is often not very well tested (because it's\r
  45 > rather hard to test), and that at least on Linux, it's unlikely that malloc\r
  46 > ever does return NULL. Lennart Poettering wrote this up in some more\r
  47 > detail[1]. Of course, the requirements for notmuch may be a bit different and\r
  48 > I definitely don't want to suggest any radical change here after only finding\r
  49 > out about notmuch a few days ago :)\r
  50 \r
  51 No problem. I'm glad to discuss things. That's how I learn and find out\r
  52 whether my decisions are sound or not. :-)\r
  53 \r
  54 I agree that trying to support OOM doesn't make sense without\r
  55 testing. But that's why I want to test notmuch with memory-fault\r
  56 injection. We've been doing this with the cairo library with good\r
  57 success for a while.\r
  58 \r
  59 As for "unlikely that malloc ever returns NULL", that's simply a\r
  60 system-configuration away (just turn off overcommit). And I can imagine\r
  61 notmuch being used in lots of places, (netbooks, web servers, etc.), so\r
  62 I do want to make it as robust as possible.\r
  63 \r
  64 > (BTW, there is a hashtable implementation in libc, (hcreate(3) etc.). Is that\r
  65 > one not sufficiently 'talloc-friendly'? It's not very user-friendly, but\r
  66 > that's another matter)\r
  67 \r
  68 Thanks for mentioning the hash table. The hash table is one of the few\r
  69 things that I *am* using from glib right now in notmuch. It's got a\r
  70 couple of bizarre things about it:\r
  71 \r
  72         1. The simpler-appearing g_hash_table_new function is useless\r
  73            for common cases like hashing strings. It will just leak\r
  74            memory. So g_hash_table_new_full is the only one worth using.\r
  75 \r
  76         2. There are two lookup functions, g_hash_table_lookup, and\r
  77            g_hash_table_lookup_extended.\r
  78 \r
  79            And a program like notmuch really does use the hash table in\r
  80            two ways. In the simpler case, we're using the hash to simply\r
  81            implement a set, (such as avoiding duplicates in a set of\r
  82            tags). In the more complex case, we're associating actual\r
  83            objects with the keys, (such as when linking messages\r
  84            together into a tree for the thread).\r
  85 \r
  86            So, it might make sense if a hash-table interface supported\r
  87            these two modes well. What's bizarre about GHashTable though,\r
  88            is that in the "just a set" case, we only use NULL as the\r
  89            value when inserting. And distinguish "previously inserted\r
  90            with NULL" from "never inserted" is the one thing that\r
  91            g_hash_table_lookup can't do. So I've only found that I could\r
  92            ever use g_hash_table_lookup_extended, (and pass a pair of\r
  93            NULLs for the return arguments I don't need).\r
  94 \r
  95 Fortunately, Eric Anholt spent *his* flight home coding up an nice\r
  96 implementation of an open-addressed hash designed specifically to be a\r
  97 tiny little implementation suitable for copying directly into\r
  98 project. He's testing it with Mesa now, and I might pull it into notmuch\r
  99 later.\r
 100 \r
 101 > I could imagine the string functions could replace the ones in talloc. There\r
 102 > are many more string functions, e.g., for handling file names / paths, which\r
 103 > are quite useful. Then there are wrappers for gcc'isms (G_UNLIKELY etc.) that\r
 104 > would make the ones in notmuch unneeded, and a lot of compatibility things\r
 105 > like G_DIR_SEPARATOR. And the datastructures (GSlice/GList/GHashtable) are\r
 106 > nice. The UTF8 functionality might come in handy.\r
 107 \r
 108 Yes. The portability stuff I think is actually interesting. I've thought\r
 109 it really might make sense to have something that gave you *just* that,\r
 110 (without a main loop, an object system, several memory allocators or\r
 111 pieces for making your own memory allocators, etc). I haven't had a\r
 112 chance to look into gnulib yet, but I'd like to.\r
 113 \r
 114 As for a list, I almost always find it cleaner to be able to just have\r
 115 my own list data structures, (to avoid casts, etc.).\r
 116 \r
 117 And for a hash table, I'm interested in what Eric's doing.\r
 118 \r
 119 I'm really not prejudiced against using code that's already been\r
 120 written, (in spite of what might appear I don't feel the need to\r
 121 re-solve every problem that's already been solved). But I have long\r
 122 thought that we could have better support for a "C programmers toolkit"\r
 123 of commonly needed things than we have before.\r
 124 \r
 125 I definitely like the idea of having tiny, focused libraries that do one\r
 126 thing and do it well, (and maybe even some things so tiny that they are\r
 127 actually designed to be copied into the application---like with gnulib\r
 128 and with Eric's new hash table).\r
 129 \r
 130 > Anyway, I was just curious, people have survived without GLib before, and if\r
 131 > you dislike the OOM-strategy, it's a bit of a no-no of course.\r
 132 \r
 133 Thanks for understanding. :-)\r
 134 \r
 135 And I enjoy the conversation,\r
 136 \r
 137 -Carl\r