lukechilds
/
lightning
mirror of https://github.com/lukechilds/lightning.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
8806 Commits
55 Branches
107 Tags
38 MiB
Tree: f0061d0606
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'f0061d0606'
${ noResults }
lightning/lightningd/plugin_hook.h

170 lines
7.8 KiB
Raw Normal View History

plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it's unlikely that we'll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker <decker.christian@gmail.com>
6 years ago
#ifndef LIGHTNING_LIGHTNINGD_PLUGIN_HOOK_H
#define LIGHTNING_LIGHTNINGD_PLUGIN_HOOK_H
#include "config.h"
#include <ccan/autodata/autodata.h>
#include <ccan/tal/tal.h>
#include <ccan/typesafe_cb/typesafe_cb.h>
common: move json_stream from lightningd/ to common/ It&#39;s not lightningd-specific and we are going to need it for libplugin. The only drawback is the log_io removal in json_stream_output_write()..
5 years ago
#include <common/json_stream.h>
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
#include <lightningd/lightningd.h>
#include <lightningd/plugin.h>
/**
* Plugin hooks are a way for plugins to implement custom behavior and
* reactions to certain things in `lightningd`. `lightningd` will ask
* plugins that have registered a hook for a given event how it'd like
* to proceed. This allows plugins to deviate from the default
* behavior that `lightningd` otherwise implements.
*
* Examples include storing an additional backup of important
* information belonging to the wallet before committing to it, or
* holding an incoming payment that is guaranteed to succeed for some
* time in order to check that the delivery of goods works correctly,
* giving the option of instantly refunding should something go wrong.
*
* Hooks are commonly structured into a number of converter functions
* and a callback. The converter functions convert from an internal
* struct representation of the method arguments to a JSON-object for
* delivery to the plugin, and from a JSON-object to the internal
* representation:
*
plugin: simplify hooks calling methods, and make lifetime requirements explicit. They callback must take ownership of the payload (almost all do, but now it&#39;s explicit). And since the payload and cb_arg arguments to plugin_hook_call_() are always identical, make them a single parameter. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
* - `serialize_payload` which takes a payload of type `cb_arg_type`
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
* and serializes it into the given `json_stream`. `
*
plugins: make chained hooks have two different callbacks. One is called on every plugin return, and tells us whether to continue; the other is only called if every plugin says ok. This works for things like payload replacement, where we need to process the results from each plugin, not just the final one! We should probably turn everything into a chained callback next release. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
* For single-plugin hooks:
* - `single_response_cb` is called once the plugin has responded (or with
lightningd: remove deserialize step for plugin hooks. This seems like overkill, at least for now. Handling the JSON inline is clearer, for the existing examples at least. We also remove the dummy hook, rather than fix it. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
* buffer == NULL if there's no plugin). In addition an arbitrary
* additional argument of type `cb_arg_type` can be passed along
plugin: simplify hooks calling methods, and make lifetime requirements explicit. They callback must take ownership of the payload (almost all do, but now it&#39;s explicit). And since the payload and cb_arg arguments to plugin_hook_call_() are always identical, make them a single parameter. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
* that may contain any additional context necessary. It must free
* or otherwise take ownership of the cb_arg_type argument.
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
*
plugins: make chained hooks have two different callbacks. One is called on every plugin return, and tells us whether to continue; the other is only called if every plugin says ok. This works for things like payload replacement, where we need to process the results from each plugin, not just the final one! We should probably turn everything into a chained callback next release. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
* For chained-plugin hooks:
* - `deserialize_cb` is called for each plugin, if it returns true the
* next one is called, otherwise the cb_arg_type argument is free.
* - If all `deserialize_cb` return true, `final_cb` is called. It must free
* or otherwise take ownership of the cb_arg_type argument.
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
*
plugins: make chained hooks have two different callbacks. One is called on every plugin return, and tells us whether to continue; the other is only called if every plugin says ok. This works for things like payload replacement, where we need to process the results from each plugin, not just the final one! We should probably turn everything into a chained callback next release. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
* To make hook invocations easier, each hook provides a `plugin_hook_call_hookname`
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
* function that performs typechecking at compile time, and makes sure
* that all the provided functions for serialization, deserialization
* and callback have the correct type.
*/
plugin: Introduce plugin type to allow singleton and chaining The newly introduced type is used to determine what the call semantics of the hook are. We have `single` corresponding to the old behavior, as well as `chain` which allows multiple plugins to register for the hook, and they are then called sequentially (if all plugins return `{&#34;result&#34;: &#34;continue&#34;}`) or exit the chain if the hook event was handled.
5 years ago
enum plugin_hook_type {
PLUGIN_HOOK_SINGLE,
PLUGIN_HOOK_CHAIN,
};
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
struct plugin_hook {
const char *name;
plugin: Introduce plugin type to allow singleton and chaining The newly introduced type is used to determine what the call semantics of the hook are. We have `single` corresponding to the old behavior, as well as `chain` which allows multiple plugins to register for the hook, and they are then called sequentially (if all plugins return `{&#34;result&#34;: &#34;continue&#34;}`) or exit the chain if the hook event was handled.
5 years ago
/* Which type of plugin is this? It'll determine how many plugins can
* register this hook, and how the hooks are called. */
enum plugin_hook_type type;
plugins: make chained hooks have two different callbacks. One is called on every plugin return, and tells us whether to continue; the other is only called if every plugin says ok. This works for things like payload replacement, where we need to process the results from each plugin, not just the final one! We should probably turn everything into a chained callback next release. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
/* For PLUGIN_HOOK_SINGLE hooks */
void (*single_response_cb)(void *arg,
const char *buffer, const jsmntok_t *toks);
/* For PLUGIN_HOOK_CHAIN hooks: */
/* Returns false if we should stop iterating (and free arg). */
bool (*deserialize_cb)(void *arg,
const char *buffer, const jsmntok_t *toks);
void (*final_cb)(void *arg);
/* To send the payload to the plugin */
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
void (*serialize_payload)(void *src, struct json_stream *dest);
plugin: Multiple plugins can register a singl hook Switch from having a single plugin to a list of plugins. If the hook is of type single we will enforce that constraint on the number of registered plugins when attempting to add.
5 years ago
/* Which plugins have registered this hook? This is a `tal_arr`
* initialized at creation. */
struct plugin **plugins;
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
};
AUTODATA_TYPE(hooks, struct plugin_hook);
/* Do not call this directly, rather use the `plugin_hook_call_name`
* wrappers generated by the `PLUGIN_HOOK_REGISTER` macro.
plugin_hook_call: return indication whether we called the callback or not. This will allow us to simplify the caller&#39;s command handling. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
*
* Returns true if callback called immediately, otherwise false if it's
* still waiting on a plugin response.
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
*/
plugin_hook_call: return indication whether we called the callback or not. This will allow us to simplify the caller&#39;s command handling. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
bool plugin_hook_call_(struct lightningd *ld, const struct plugin_hook *hook,
plugin: simplify hooks calling methods, and make lifetime requirements explicit. They callback must take ownership of the payload (almost all do, but now it&#39;s explicit). And since the payload and cb_arg arguments to plugin_hook_call_() are always identical, make them a single parameter. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
tal_t *cb_arg STEALS);
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
plugins: make chained hooks have two different callbacks. One is called on every plugin return, and tells us whether to continue; the other is only called if every plugin says ok. This works for things like payload replacement, where we need to process the results from each plugin, not just the final one! We should probably turn everything into a chained callback next release. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
/* Generic deserialize_cb: returns true iff 'result': 'continue' */
bool plugin_hook_continue(void *arg, const char *buffer, const jsmntok_t *toks);
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
/* Create a small facade in from of `plugin_hook_call_` to make sure
* arguments are of the correct type before downcasting them to `void
* *`. Not really necessary, but nice since it also makes sure that
* the method-name is correct for the call.
*/
/* FIXME: Find a way to avoid back-to-back declaration and definition */
plugin: simplify hooks calling methods, and make lifetime requirements explicit. They callback must take ownership of the payload (almost all do, but now it&#39;s explicit). And since the payload and cb_arg arguments to plugin_hook_call_() are always identical, make them a single parameter. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
#define PLUGIN_HOOK_CALL_DEF(name, cb_arg_type) \
plugin_hook_call: return indication whether we called the callback or not. This will allow us to simplify the caller&#39;s command handling. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
UNNEEDED static inline bool plugin_hook_call_##name( \
plugin: simplify hooks calling methods, and make lifetime requirements explicit. They callback must take ownership of the payload (almost all do, but now it&#39;s explicit). And since the payload and cb_arg arguments to plugin_hook_call_() are always identical, make them a single parameter. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
struct lightningd *ld, cb_arg_type cb_arg STEALS) \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
{ \
plugin_hook_call: return indication whether we called the callback or not. This will allow us to simplify the caller&#39;s command handling. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
return plugin_hook_call_(ld, &name##_hook_gen, cb_arg); \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
}
/* Typechecked registration of a plugin hook. We check that the
* serialize_payload function converts an object of type payload_type
* to a json_stream (.params object in the JSON-RPC request), that the
* deserialize_response function converts from the JSON-RPC response
* json_stream to an object of type response_type and that the
* response_cb function accepts the deserialized response format and
* an arbitrary extra argument used to maintain context.
*/
plugins: make chained hooks have two different callbacks. One is called on every plugin return, and tells us whether to continue; the other is only called if every plugin says ok. This works for things like payload replacement, where we need to process the results from each plugin, not just the final one! We should probably turn everything into a chained callback next release. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
#define REGISTER_SINGLE_PLUGIN_HOOK(name, response_cb, \
serialize_payload, cb_arg_type) \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
struct plugin_hook name##_hook_gen = { \
stringify(name), \
plugins: make chained hooks have two different callbacks. One is called on every plugin return, and tells us whether to continue; the other is only called if every plugin says ok. This works for things like payload replacement, where we need to process the results from each plugin, not just the final one! We should probably turn everything into a chained callback next release. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
PLUGIN_HOOK_SINGLE, \
plugin: Introduce plugin type to allow singleton and chaining The newly introduced type is used to determine what the call semantics of the hook are. We have `single` corresponding to the old behavior, as well as `chain` which allows multiple plugins to register for the hook, and they are then called sequentially (if all plugins return `{&#34;result&#34;: &#34;continue&#34;}`) or exit the chain if the hook event was handled.
5 years ago
typesafe_cb_cast( \
plugin: simplify hooks calling methods, and make lifetime requirements explicit. They callback must take ownership of the payload (almost all do, but now it&#39;s explicit). And since the payload and cb_arg arguments to plugin_hook_call_() are always identical, make them a single parameter. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
void (*)(void *STEALS, const char *, const jsmntok_t *), \
void (*)(cb_arg_type STEALS, const char *, const jsmntok_t *), \
plugin: Introduce plugin type to allow singleton and chaining The newly introduced type is used to determine what the call semantics of the hook are. We have `single` corresponding to the old behavior, as well as `chain` which allows multiple plugins to register for the hook, and they are then called sequentially (if all plugins return `{&#34;result&#34;: &#34;continue&#34;}`) or exit the chain if the hook event was handled.
5 years ago
response_cb), \
plugins: make chained hooks have two different callbacks. One is called on every plugin return, and tells us whether to continue; the other is only called if every plugin says ok. This works for things like payload replacement, where we need to process the results from each plugin, not just the final one! We should probably turn everything into a chained callback next release. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
NULL, NULL, \
typesafe_cb_cast(void (*)(void *, struct json_stream *), \
void (*)(cb_arg_type, struct json_stream *), \
serialize_payload), \
NULL, /* .plugins */ \
}; \
AUTODATA(hooks, &name##_hook_gen); \
PLUGIN_HOOK_CALL_DEF(name, cb_arg_type)
#define REGISTER_PLUGIN_HOOK(name, deserialize_cb, final_cb, \
serialize_payload, cb_arg_type) \
struct plugin_hook name##_hook_gen = { \
stringify(name), \
PLUGIN_HOOK_CHAIN, \
NULL, \
typesafe_cb_cast( \
bool (*)(void *, const char *, const jsmntok_t *), \
bool (*)(cb_arg_type, const char *, const jsmntok_t *), \
deserialize_cb), \
typesafe_cb_cast( \
void (*)(void *STEALS), \
void (*)(cb_arg_type STEALS), \
final_cb), \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
typesafe_cb_cast(void (*)(void *, struct json_stream *), \
plugin: simplify hooks calling methods, and make lifetime requirements explicit. They callback must take ownership of the payload (almost all do, but now it&#39;s explicit). And since the payload and cb_arg arguments to plugin_hook_call_() are always identical, make them a single parameter. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
void (*)(cb_arg_type, struct json_stream *), \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
serialize_payload), \
plugin: Multiple plugins can register a singl hook Switch from having a single plugin to a list of plugins. If the hook is of type single we will enforce that constraint on the number of registered plugins when attempting to add.
5 years ago
NULL, /* .plugins */ \
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
}; \
AUTODATA(hooks, &name##_hook_gen); \
plugin: simplify hooks calling methods, and make lifetime requirements explicit. They callback must take ownership of the payload (almost all do, but now it&#39;s explicit). And since the payload and cb_arg arguments to plugin_hook_call_() are always identical, make them a single parameter. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
5 years ago
PLUGIN_HOOK_CALL_DEF(name, cb_arg_type)
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
bool plugin_hook_register(struct plugin *plugin, const char *method);
lightningd/plugin_hook: make it possible to unregister a hook This adds &#39;plugin_unregister_hook&#39; and &#39;plugin_unregister_hook_all&#39; functions to unregister a given hook a plugin registered, or all hooks a plugin registered for. Since hooks can only be registered once, it&#39;s useful in the case a new plugin is added which would be prefered for hook registration over an already loaded plugin.
6 years ago
/* Unregister a hook a plugin has registered for */
bool plugin_hook_unregister(struct plugin *plugin, const char *method);
/* Unregister all hooks a plugin has registered for */
void plugin_hook_unregister_all(struct plugin *plugin);
db: Consolidate access to the changes in a db We were passing them in separately, while we could just retrieve them from the db instance instead.
5 years ago
/* Special sync plugin hook for db. */
void plugin_hook_db_sync(struct db *db);
plugin_hook: special case for db hook. I started by trying to change the current infrastructure, but this is really the only completely sync hook which makes sense; it needs to avoid doing the db_transation, as well as waiting, and using a callback is just overkill. So with some regret, I open coded it. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
plugin: Add hook registration I might have gone a bit overboard with the type-checking, but typesafe_cb_cast is quite nice to use, so why not. The macro to register a new hook encapsulates the entire flow from param serialization, to dispatch, parsing and callback dispatch in one bundle. I was tempted to have the callback outside of the registration, but it&#39;s unlikely that we&#39;ll have two calls to the same hook with different callbacks. Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
#endif /* LIGHTNING_LIGHTNINGD_PLUGIN_HOOK_H */