MCPcopy Create free account
hub / github.com/ElementsProject/lightning / jcon_connected

Function jcon_connected

lightningd/jsonrpc.c:1097–1132  ·  view source on GitHub ↗

Source from the content-addressed store, hash-verified

1095}
1096
1097static struct io_plan *jcon_connected(struct io_conn *conn,
1098 struct lightningd *ld)
1099{
1100 struct json_connection *jcon;
1101
1102 /* We live as long as the connection, so we're not a leak. */
1103 jcon = notleak(tal(conn, struct json_connection));
1104 jcon->conn = conn;
1105 jcon->ld = ld;
1106 jcon->used = 0;
1107 jcon->buffer = tal_arr(jcon, char, 64);
1108 jcon->js_arr = tal_arr(jcon, struct json_stream *, 0);
1109 jcon->len_read = 0;
1110 jsmn_init(&jcon->input_parser);
1111 jcon->input_toks = toks_alloc(jcon);
1112 jcon->notifications_enabled = false;
1113 jcon->db_batching = false;
1114 list_head_init(&jcon->commands);
1115
1116 /* We want to log on destruction, so we free this in destructor. */
1117 jcon->log = new_log(ld->log_book, ld->log_book, NULL, "jsonrpc#%i",
1118 io_conn_fd(conn));
1119
1120 tal_add_destructor(jcon, destroy_jcon);
1121
1122 /* Note that write_json and read_json alternate manually, by waking
1123 * each other. It would be simpler to not use a duplex io, and have
1124 * read_json parse one command, then io_wait() for command completion
1125 * and go to write_json.
1126 *
1127 * However, if we ever have notifications, this neat cmd-response
1128 * pattern would break down, so we use this trick. */
1129 return io_duplex(conn,
1130 read_json(conn, jcon),
1131 start_json_stream(conn, jcon));
1132}
1133
1134static struct io_plan *incoming_jcon_connected(struct io_conn *conn,
1135 struct lightningd *ld)

Callers 1

incoming_jcon_connectedFunction · 0.85

Calls 7

list_head_initFunction · 0.85
io_conn_fdFunction · 0.85
io_duplexFunction · 0.85
read_jsonFunction · 0.85
start_json_streamFunction · 0.85
new_logFunction · 0.70
toks_allocFunction · 0.50

Tested by

no test coverage detected