~ The core lightning object: it's passed everywhere, and is basically a * global variable. This new_xxx pattern is something we'll see often: * it allocates and initializes a new structure, using *tal*, the hierarchical * allocator. */
| 88 | * it allocates and initializes a new structure, using *tal*, the hierarchical |
| 89 | * allocator. */ |
| 90 | static struct lightningd *new_lightningd(const tal_t *ctx) |
| 91 | { |
| 92 | /*~ tal: each allocation is a child of an existing object (or NULL, |
| 93 | * the top-level object). When an object is freed, all the objects |
| 94 | * `tallocated` off it are also freed. We use it in place of malloc |
| 95 | * and free. For the technically inclined: tal allocations usually |
| 96 | * build a tree, and tal_freeing any node in the tree will result in |
| 97 | * the entire subtree rooted at that node to be freed. |
| 98 | * |
| 99 | * It's incredibly useful for grouping object lifetimes, as we'll see. |
| 100 | * For example, a `struct lightningd` has a pointer to a `log_book` |
| 101 | * which is allocated off the `struct lightningd`, and has its own |
| 102 | * internal members allocated off `log_book`: freeing `struct |
| 103 | * lightningd` frees them all. |
| 104 | * |
| 105 | * In this case, freeing `ctx` will free `ld`: |
| 106 | */ |
| 107 | struct lightningd *ld = tal(ctx, struct lightningd); |
| 108 | |
| 109 | /*~ Style note: `ctx` is declared `const`, yet we can `tallocate` from |
| 110 | * it. Adding/removing children is not considered to change an |
| 111 | * object; nor, in fact, is freeing it with tal_free(). This allows |
| 112 | * us to use const more liberally: the style rule here is that you |
| 113 | * should use 'const' on pointers if you can. */ |
| 114 | |
| 115 | /*~ Note that we generally EXPLICITLY #if-wrap DEVELOPER code. This |
| 116 | * is a nod to keeping it minimal and explicit: we need this code for |
| 117 | * testing, but its existence means we're not actually testing the |
| 118 | * same exact code users will be running. */ |
| 119 | #if DEVELOPER |
| 120 | ld->dev_debug_subprocess = NULL; |
| 121 | ld->dev_no_plugin_checksum = false; |
| 122 | ld->dev_disconnect_fd = -1; |
| 123 | ld->dev_subdaemon_fail = false; |
| 124 | ld->dev_allow_localhost = false; |
| 125 | ld->dev_gossip_time = 0; |
| 126 | ld->dev_fast_gossip = false; |
| 127 | ld->dev_fast_gossip_prune = false; |
| 128 | ld->dev_fast_reconnect = false; |
| 129 | ld->dev_force_privkey = NULL; |
| 130 | ld->dev_force_bip32_seed = NULL; |
| 131 | ld->dev_force_channel_secrets = NULL; |
| 132 | ld->dev_force_channel_secrets_shaseed = NULL; |
| 133 | ld->dev_force_tmp_channel_id = NULL; |
| 134 | ld->dev_no_htlc_timeout = false; |
| 135 | ld->dev_no_version_checks = false; |
| 136 | ld->dev_max_funding_unconfirmed = 2016; |
| 137 | ld->dev_ignore_modern_onion = false; |
| 138 | ld->dev_disable_commit = -1; |
| 139 | ld->dev_no_ping_timer = false; |
| 140 | #endif |
| 141 | |
| 142 | /*~ These are CCAN lists: an embedded double-linked list. It's not |
| 143 | * really typesafe, but relies on convention to access the contents. |
| 144 | * It's inspired by the closely-related Linux kernel list.h. |
| 145 | * |
| 146 | * You declare them as a `struct list_head` (or use the LIST_HEAD() |
| 147 | * macro which doesn't work on dynamically-allocated objects like `ld` |
no test coverage detected