Mercurial > hg > xemacs-beta
comparison src/elhash.c @ 497:11b53bb7daf5
[xemacs-hg @ 2001-05-02 10:22:58 by martinb]
better comment
| author | martinb |
|---|---|
| date | Wed, 02 May 2001 10:22:58 +0000 |
| parents | 4a8bb4aa9740 |
| children | bcda0b3445a6 |
comparison
equal
deleted
inserted
replaced
| 496:98145293255c | 497:11b53bb7daf5 |
|---|---|
| 1209 hash table might be modified during the mapping operation: | 1209 hash table might be modified during the mapping operation: |
| 1210 - by the mapping function | 1210 - by the mapping function |
| 1211 - by gc (if the hash table is weak) | 1211 - by gc (if the hash table is weak) |
| 1212 | 1212 |
| 1213 So we make a copy of the hentries at the beginning of the mapping | 1213 So we make a copy of the hentries at the beginning of the mapping |
| 1214 operation, and iterate over the copy. */ | 1214 operation, and iterate over the copy. Naturally, this is |
| 1215 expensive, but not as expensive as you might think, because no | |
| 1216 actual memory has to be collected by our notoriously inefficient | |
| 1217 GC; we use an unwind-protect instead to free the memory directly. | |
| 1218 | |
| 1219 We could avoid the copying by having the hash table modifiers | |
| 1220 puthash and remhash check for currently active mapping functions. | |
| 1221 Disadvantages: it's hard to get right, and IMO hash mapping | |
| 1222 functions are basically rare, and no extra space in the hash table | |
| 1223 object and no extra cpu in puthash or remhash should be wasted to | |
| 1224 make maphash 3% faster. From a design point of view, the basic | |
| 1225 functions gethash, puthash and remhash should be implementable | |
| 1226 without having to think about maphash. | |
| 1227 | |
| 1228 Note: We don't (yet) have Common Lisp's with-hash-table-iterator. | |
| 1229 If you implement this naively, you cannot have more than one | |
| 1230 concurrently active iterator over the same hash table. The `each' | |
| 1231 function in perl has this limitation. | |
| 1232 | |
| 1233 Note: We GCPRO memory on the heap, not on the stack. There is no | |
| 1234 obvious reason why this is bad, but as of this writing this is the | |
| 1235 only known occurrence of this technique in the code. | |
| 1236 */ | |
| 1237 | |
| 1215 static Lisp_Object | 1238 static Lisp_Object |
| 1216 maphash_unwind (Lisp_Object unwind_obj) | 1239 maphash_unwind (Lisp_Object unwind_obj) |
| 1217 { | 1240 { |
| 1218 void *ptr = (void *) get_opaque_ptr (unwind_obj); | 1241 void *ptr = (void *) get_opaque_ptr (unwind_obj); |
| 1219 xfree (ptr); | 1242 xfree (ptr); |