diff options
Diffstat (limited to 'src/core/or/scheduler_kist.c')
-rw-r--r-- | src/core/or/scheduler_kist.c | 15 |
1 files changed, 11 insertions, 4 deletions
diff --git a/src/core/or/scheduler_kist.c b/src/core/or/scheduler_kist.c index e56942be09..c73d768f88 100644 --- a/src/core/or/scheduler_kist.c +++ b/src/core/or/scheduler_kist.c @@ -56,9 +56,9 @@ typedef HT_HEAD(socket_table_s, socket_table_ent_t) socket_table_t; static socket_table_t socket_table = HT_INITIALIZER(); HT_PROTOTYPE(socket_table_s, socket_table_ent_t, node, socket_table_ent_hash, - socket_table_ent_eq) + socket_table_ent_eq); HT_GENERATE2(socket_table_s, socket_table_ent_t, node, socket_table_ent_hash, - socket_table_ent_eq, 0.6, tor_reallocarray, tor_free_) + socket_table_ent_eq, 0.6, tor_reallocarray, tor_free_); /* outbuf_table hash table stuff. The outbuf_table keeps track of which * channels have data sitting in their outbuf so the kist scheduler can force @@ -83,9 +83,9 @@ outbuf_table_ent_eq(const outbuf_table_ent_t *a, const outbuf_table_ent_t *b) } HT_PROTOTYPE(outbuf_table_s, outbuf_table_ent_t, node, outbuf_table_ent_hash, - outbuf_table_ent_eq) + outbuf_table_ent_eq); HT_GENERATE2(outbuf_table_s, outbuf_table_ent_t, node, outbuf_table_ent_hash, - outbuf_table_ent_eq, 0.6, tor_reallocarray, tor_free_) + outbuf_table_ent_eq, 0.6, tor_reallocarray, tor_free_); /***************************************************************************** * Other internal data @@ -463,6 +463,13 @@ MOCK_IMPL(void, channel_write_to_kernel, (channel_t *chan)) log_debug(LD_SCHED, "Writing %lu bytes to kernel for chan %" PRIu64, (unsigned long)channel_outbuf_length(chan), chan->global_identifier); + /* Note that 'connection_handle_write()' may change the scheduler state of + * the channel during the scheduling loop with + * 'connection_or_flushed_some()' -> 'scheduler_channel_wants_writes()'. + * This side-effect will only occur if the channel is currently in the + * 'SCHED_CHAN_WAITING_TO_WRITE' or 'SCHED_CHAN_IDLE' states, which KIST + * rarely uses, so it should be fine unless KIST begins using these states + * in the future. */ connection_handle_write(TO_CONN(BASE_CHAN_TO_TLS(chan)->conn), 0); } |