Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order specifications for hooks #4168

Merged
merged 12 commits into from
Nov 9, 2020
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions common/utils.h
Original file line number Diff line number Diff line change
Expand Up @@ -47,9 +47,9 @@ void clear_softref_(const tal_t *outer, size_t outersize, void **ptr);
/* Note: p is never a complex expression, otherwise this multi-evaluates! */
#define tal_arr_expand(p, s) \
do { \
size_t n = tal_count(*(p)); \
tal_resize((p), n+1); \
(*(p))[n] = (s); \
size_t n_ = tal_count(*(p)); \
tal_resize((p), n_+1); \
(*(p))[n_] = (s); \
} while(0)

/**
Expand Down
13 changes: 10 additions & 3 deletions doc/PLUGINS.md
Original file line number Diff line number Diff line change
Expand Up @@ -93,8 +93,8 @@ example:
"disconnect"
],
"hooks": [
"openchannel",
"htlc_accepted"
{ "name": "openchannel", "before": ["another_plugin"] },
{ "name": "htlc_accepted" }
],
"features": {
"node": "D0000000",
Expand Down Expand Up @@ -678,13 +678,20 @@ declares that it'd like to be consulted on what to do next for certain
events in the daemon. A hook can then decide how `lightningd` should
react to the given event.

When hooks are registered, they can optionally specify "before" and
"after" arrays of plugin names, which control what order they will be
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

General question about 'plugin names': Is this same as for cli plugin start/stop commands, meaning either full path (useless for this feature) or basename? If so, we may note that the plugin name includes its extension, meaning full filename.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, filename or full path name.

called in. If a plugin name is unknown, it is ignored, otherwise if the
hook calls cannot be ordered to satisfy the specifications of all
plugin hooks, the plugin registration will fail.

The call semantics of the hooks, i.e., when and how hooks are called, depend
on the hook type. Most hooks are currently set to `single`-mode. In this mode
only a single plugin can register the hook, and that plugin will get called
for each event of that type. If a second plugin attempts to register the hook
it gets killed and a corresponding log entry will be added to the logs. In
`chain`-mode multiple plugins can register for the hook type and they are
called sequentially if a matching event is triggered. Each plugin can then
called in any order which meets their `before` and `after` requirements
if a matching event is triggered. Each plugin can then
handle the event or defer by returning a `continue` result like the following:

```json
Expand Down
40 changes: 34 additions & 6 deletions lightningd/plugin.c
Original file line number Diff line number Diff line change
Expand Up @@ -117,7 +117,6 @@ static void destroy_plugin(struct plugin *p)
{
struct plugin_rpccall *call;

plugin_hook_unregister_all(p);
list_del(&p->list);

/* Terminate all pending RPC calls with an error. */
Expand Down Expand Up @@ -1057,20 +1056,49 @@ static const char *plugin_subscriptions_add(struct plugin *plugin,
static const char *plugin_hooks_add(struct plugin *plugin, const char *buffer,
const jsmntok_t *resulttok)
{
const jsmntok_t *hookstok = json_get_member(buffer, resulttok, "hooks");
const jsmntok_t *t, *hookstok, *beforetok, *aftertok;
size_t i;

hookstok = json_get_member(buffer, resulttok, "hooks");
if (!hookstok)
return NULL;

for (int i = 0; i < hookstok->size; i++) {
char *name = json_strdup(tmpctx, plugin->buffer,
json_get_arr(hookstok, i));
if (!plugin_hook_register(plugin, name)) {
json_for_each_arr(i, t, hookstok) {
char *name, *depfail;
struct plugin_hook *hook;

if (t->type == JSMN_OBJECT) {
const jsmntok_t *nametok;

nametok = json_get_member(buffer, t, "name");
if (!nametok)
return tal_fmt(plugin, "no name in hook obj %.*s",
json_tok_full_len(t),
json_tok_full(buffer, t));
name = json_strdup(tmpctx, buffer, nametok);
beforetok = json_get_member(buffer, t, "before");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it took me a second to fully grasp the implication of 'before' and 'after'. Renaming them to "run_before" and "run_after" might be more immediately obvious?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's more obvious in context, than when reading in a patch, e.g.:

"hooks": [
    {"name": "htlc_accepted",
     "before": ["someplugin.py"],
     "after": ["foo.py"]}
]

aftertok = json_get_member(buffer, t, "after");
} else {
name = json_strdup(tmpctx, plugin->buffer, t);
beforetok = aftertok = NULL;
}

hook = plugin_hook_register(plugin, name);
if (!hook) {
return tal_fmt(plugin,
"could not register hook '%s', either the "
"name doesn't exist or another plugin "
"already registered it.",
name);
}

plugin_hook_add_deps(hook, plugin, buffer, beforetok, aftertok);
depfail = plugin_hook_make_ordered(tmpctx, hook);
if (depfail)
return tal_fmt(plugin,
"Cannot correctly order hook %s:"
"conflicts in %s",
name, depfail);
tal_free(name);
}
return NULL;
Expand Down
Loading