|
12 | 12 | * |
13 | 13 | * Comments beginning with a ~ (like this one!) are part of our shared |
14 | 14 | * adventure through the source, so they're more meta than normal code |
15 | | - * comments, and mean to be read in a certain order. |
| 15 | + * comments, and meant to be read in a certain order. |
16 | 16 | */ |
17 | 17 |
|
18 | 18 | /*~ Notice how includes are in ASCII order: this is actually enforced by |
@@ -87,7 +87,9 @@ static struct lightningd *new_lightningd(const tal_t *ctx) |
87 | 87 | /*~ tal: each allocation is a child of an existing object (or NULL, |
88 | 88 | * the top-level object). When an object is freed, all the objects |
89 | 89 | * `tallocated` off it are also freed. We use it in place of malloc |
90 | | - * and free. |
| 90 | + * and free. For the technically inclined: tal allocations usually |
| 91 | + * build a tree, and tal_freeing any node in the tree will result in |
| 92 | + * the entire subtree rooted at that node to be freed. |
91 | 93 | * |
92 | 94 | * It's incredibly useful for grouping object lifetimes, as we'll see. |
93 | 95 | * For example, a `struct bitcoin_tx` has a pointer to an array of |
@@ -142,7 +144,7 @@ static struct lightningd *new_lightningd(const tal_t *ctx) |
142 | 144 |
|
143 | 145 | /*~ These are hash tables of incoming and outgoing HTLCs (contracts), |
144 | 146 | * defined as `struct htlc_in` and `struct htlc_out`in htlc_end.h. |
145 | | - * The hash tables are declared ther using the very ugly |
| 147 | + * The hash tables are declared there using the very ugly |
146 | 148 | * HTABLE_DEFINE_TYPE macro. The key is the channel the HTLC is in |
147 | 149 | * and the 64-bit htlc-id which is unique for that channel and |
148 | 150 | * direction. That htlc-id is used in the inter-peer wire protocol, |
@@ -258,7 +260,7 @@ void test_subdaemons(const struct lightningd *ld) |
258 | 260 | /*~ Our logging system: spam goes in at log_debug level, but |
259 | 261 | * logging is mainly added by developer necessity and removed |
260 | 262 | * by developer/user complaints . The only strong convention |
261 | | - * is that log_broken() is used for "should never happen". |
| 263 | + * is that log_broken() is used for "should never happen". |
262 | 264 | * |
263 | 265 | * Note, however, that logging takes care to preserve the |
264 | 266 | * global `errno` which is set above. */ |
|
0 commit comments