diff options
| author | Vsevolod Stakhov <vsevolod@rspamd.com> | 2022-10-23 18:07:22 +0100 |
|---|---|---|
| committer | Vsevolod Stakhov <vsevolod@rspamd.com> | 2022-10-23 18:07:22 +0100 |
| commit | b1d1a3c45e9447ac9de3a2a17901366fe821e5f4 (patch) | |
| tree | 596e0bb4397b85ef5452edb2679a7d3d5cb116fe | |
| parent | 5a13ff46447fc15c3c941517681525eed0d4a458 (diff) | |
| download | rspamd-b1d1a3c45e9447ac9de3a2a17901366fe821e5f4.tar.gz rspamd-b1d1a3c45e9447ac9de3a2a17901366fe821e5f4.zip | |
[Rework] Use blocking socket for IPC between main and workers
There are no reasons why control pipes are blocking: the messages
there are rare and are strictly bounded by command sizes, so if we block
on some pipe, it is ok, as we still poll that for all operations.
It is also impossible to block on writing in normal conditions.
And if the conditions are not normal, e.g. a worker is unresponsive, then
we can safely think that the non-blocking behaviour as it is implemented
currently will not make things better, as it would lead to incomplete
reads/writes that are not handled anyhow and are totally broken from the
beginning.
| -rw-r--r-- | src/libserver/worker_util.c | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/src/libserver/worker_util.c b/src/libserver/worker_util.c index d8c62d210..4529e4ee0 100644 --- a/src/libserver/worker_util.c +++ b/src/libserver/worker_util.c @@ -1175,8 +1175,14 @@ rspamd_handle_child_fork (struct rspamd_worker *wrk, /* Close parent part of socketpair */ close (wrk->control_pipe[0]); close (wrk->srv_pipe[0]); + /* + * Read comments in `rspamd_handle_main_fork` for details why these channel + * is blocking. + */ +#if 0 rspamd_socket_nonblocking (wrk->control_pipe[1]); rspamd_socket_nonblocking (wrk->srv_pipe[1]); +#endif rspamd_main->cfg->cur_worker = wrk; /* Execute worker (this function should not return normally!) */ cf->worker->worker_start_func (wrk); @@ -1194,8 +1200,21 @@ rspamd_handle_main_fork (struct rspamd_worker *wrk, close (wrk->control_pipe[1]); close (wrk->srv_pipe[1]); + /* + * There are no reasons why control pipes are blocking: the messages + * there are rare and are strictly bounded by command sizes, so if we block + * on some pipe, it is ok, as we still poll that for all operations. + * It is also impossible to block on writing in normal conditions. + * And if the conditions are not normal, e.g. a worker is unresponsive, then + * we can safely think that the non-blocking behaviour as it is implemented + * currently will not make things better, as it would lead to incomplete + * reads/writes that are not handled anyhow and are totally broken from the + * beginning. + */ +#if 0 rspamd_socket_nonblocking (wrk->control_pipe[0]); rspamd_socket_nonblocking (wrk->srv_pipe[0]); +#endif rspamd_srv_start_watching (rspamd_main, wrk, ev_base); /* Child event */ wrk->cld_ev.data = wrk; |