Mirrors/fish-shell
2
0
Fork 0
mirror of https://github.com/fish-shell/fish-shell synced 2025-01-02 16:18:44 +00:00
Code Issues Projects Releases Packages Wiki Activity
fish-shell/src/topic_monitor.cpp

284 lines
10 KiB
C++
Raw Normal View History

Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
#include "config.h" // IWYU pragma: keep
#include "topic_monitor.h"
#include <unistd.h>
IWYU-guided #include rejiggering. Let's hope this doesn't causes build failures for e.g. musl: I just know it's good on macOS and our Linux CI. It's been a long time. One fix this brings, is I discovered we #include assert.h or cassert in a lot of places. If those ever happen to be in a file that doesn't include common.h, or we are before common.h gets included, we're unawaringly working with the system 'assert' macro again, which may get disabled for debug builds or at least has different behavior on crash. We undef 'assert' and redefine it in common.h. Those were all eliminated, except in one catch-22 spot for maybe.h: it can't include common.h. A fix might be to make a fish_assert.h that *usually* common.h exports.
2022-08-21 06:14:48 +00:00
#include <cerrno>
Run clang-format on all files The main change here is to reorder headers.
2019-10-13 22:50:48 +00:00
#include "flog.h"
#include "iothread.h"
IWYU-guided #include rejiggering. Let's hope this doesn't causes build failures for e.g. musl: I just know it's good on macOS and our Linux CI. It's been a long time. One fix this brings, is I discovered we #include assert.h or cassert in a lot of places. If those ever happen to be in a file that doesn't include common.h, or we are before common.h gets included, we're unawaringly working with the system 'assert' macro again, which may get disabled for debug builds or at least has different behavior on crash. We undef 'assert' and redefine it in common.h. Those were all eliminated, except in one catch-22 spot for maybe.h: it can't include common.h. A fix might be to make a fish_assert.h that *usually* common.h exports.
2022-08-21 06:14:48 +00:00
#include "maybe.h"
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
#include "wcstringutil.h"
Run clang-format on all files The main change here is to reorder headers.
2019-10-13 22:50:48 +00:00
#include "wutil.h"
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
wcstring generation_list_t::describe() const {
wcstring result;
for (generation_t gen : this->as_array()) {
if (!result.empty()) result.push_back(L',');
if (gen == invalid_generation) {
result.append(L"-1");
} else {
result.append(to_string(gen));
}
}
return result;
}
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
binary_semaphore_t::binary_semaphore_t() : sem_ok_(false) {
// sem_init always fails with ENOSYS on Mac and has an annoying deprecation warning.
Use anon semaphores only on Linux On BSDs, anonymous semaphores are implemented using a file descriptor which is not marked CLOEXEC, so it gets leaked into child processes. Use ordinary pipes instead of semaphores everywhere except Linux. Fixes #7304
2020-09-05 19:38:21 +00:00
// On BSD sem_init uses a file descriptor under the hood which doesn't get CLOEXEC (see #7304).
// So use fast semaphores on Linux only.
#ifdef __linux__
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
sem_ok_ = (0 == sem_init(&sem_, 0, 0));
#endif
if (!sem_ok_) {
Pipe fds to move to the "high range" This concerns how fish prevents its own fds from interfering with user-defined fd redirections, like `echo hi >&5`. fish has historically done this by tracking all user defined redirections when running a job, and ensuring that pipes are not assigned the same fds. However this is annoying to pass around - it means that we have to thread user-defined redirections into pipe creation. Take a page from zsh and just ensure that all pipes we create have fds in the "high range," which here means at least 10. The primary way to do this is via the F_DUPFD_CLOEXEC syscall, which also sets CLOEXEC, so we aren't invoking additional syscalls in the common case. This will free us from having to track which fds are in user-defined redirections.
2021-02-03 04:30:52 +00:00
auto pipes = make_autoclose_pipes();
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
assert(pipes.has_value() && "Failed to make pubsub pipes");
pipes_ = pipes.acquire();
Unify thread sanitizer detection We now have two files that need to know if thread sanitizer is enabled. They can share the detection code.
2021-02-07 06:17:16 +00:00
// Whoof. Thread Sanitizer swallows signals and replays them at its leisure, at the point
// where instrumented code makes certain blocking calls. But tsan cannot interrupt a signal
// call, so if we're blocked in read() (like the topic monitor wants to be!), we'll never
// receive SIGCHLD and so deadlock. So if tsan is enabled, we mark our fd as non-blocking
// (so reads will never block) and use select() to poll it.
#ifdef FISH_TSAN_WORKAROUNDS
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
DIE_ON_FAILURE(make_fd_nonblocking(pipes_.read.fd()));
#endif
}
}
binary_semaphore_t::~binary_semaphore_t() {
Fix binary_semaphore_t under non-Linux TSan Under non-Linux builds, binary_semaphore is implemented with a self-pipe. When TSan is active we mark the pipe as non-blocking as TSan cannot interrupt read (but can interrupt select). However we weren't properly testing for EAGAIN leading to an assertion failure. Allow looping on EAGAIN.
2021-02-06 22:39:07 +00:00
// We never use sem_t on Mac. The #ifdef avoids deprecation warnings.
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
#ifndef __APPLE__
if (sem_ok_) (void)sem_destroy(&sem_);
#endif
}
void binary_semaphore_t::die(const wchar_t *msg) const {
wperror(msg);
DIE("unexpected failure");
}
void binary_semaphore_t::post() {
if (sem_ok_) {
int res = sem_post(&sem_);
// sem_post is non-interruptible.
if (res < 0) die(L"sem_post");
} else {
// Write exactly one byte.
ssize_t ret;
do {
const uint8_t v = 0;
ret = write(pipes_.write.fd(), &v, sizeof v);
} while (ret < 0 && errno == EINTR);
if (ret < 0) die(L"write");
}
}
void binary_semaphore_t::wait() {
if (sem_ok_) {
int res;
do {
res = sem_wait(&sem_);
} while (res < 0 && errno == EINTR);
// Other errors here are very unexpected.
if (res < 0) die(L"sem_wait");
} else {
int fd = pipes_.read.fd();
// We must read exactly one byte.
for (;;) {
Unify thread sanitizer detection We now have two files that need to know if thread sanitizer is enabled. They can share the detection code.
2021-02-07 06:17:16 +00:00
#ifdef FISH_TSAN_WORKAROUNDS
Fix binary_semaphore_t under non-Linux TSan Under non-Linux builds, binary_semaphore is implemented with a self-pipe. When TSan is active we mark the pipe as non-blocking as TSan cannot interrupt read (but can interrupt select). However we weren't properly testing for EAGAIN leading to an assertion failure. Allow looping on EAGAIN.
2021-02-06 22:39:07 +00:00
// Under tsan our notifying pipe is non-blocking, so we would busy-loop on the read()
// call until data is available (that is, fish would use 100% cpu while waiting for
Allow using poll() to check for readability Cygwin tests are failing because cygwin has a low limit of only 64 fds in select(). Extend select_wrapper_t to also support using poll(), according to a FISH_USE_POLL new define. All systems now use poll() except for Mac. Rename select_wrapper_t to fd_readable_set_t since now it may not wrap select(). This allows the deep-cmdsub.fish test to pass on Cygwin.
2022-01-02 23:25:12 +00:00
// processes). This call prevents that.
(void)fd_readable_set_t::is_fd_readable(fd, fd_readable_set_t::kNoTimeout);
Fix binary_semaphore_t under non-Linux TSan Under non-Linux builds, binary_semaphore is implemented with a self-pipe. When TSan is active we mark the pipe as non-blocking as TSan cannot interrupt read (but can interrupt select). However we weren't properly testing for EAGAIN leading to an assertion failure. Allow looping on EAGAIN.
2021-02-06 22:39:07 +00:00
#endif
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
uint8_t ignored;
auto amt = read(fd, &ignored, sizeof ignored);
if (amt == 1) break;
Fix binary_semaphore_t under non-Linux TSan Under non-Linux builds, binary_semaphore is implemented with a self-pipe. When TSan is active we mark the pipe as non-blocking as TSan cannot interrupt read (but can interrupt select). However we weren't properly testing for EAGAIN leading to an assertion failure. Allow looping on EAGAIN.
2021-02-06 22:39:07 +00:00
// EAGAIN should only be returned in TSan case.
Allow for EWOULDBLOCK instead of EAGAIN Posix allows this as an alternative with the same semantics for read. Found in conjunction with #9067. Should be no functional difference on other systems.
2022-07-23 21:15:55 +00:00
if (amt < 0 && errno != EINTR && errno != EAGAIN && errno != EWOULDBLOCK) die(L"read");
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
}
}
}
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
/// Implementation of the principal monitor. This uses new (and leaks) to avoid registering a
/// pointless at-exit handler for the dtor.
static topic_monitor_t *const s_principal = new topic_monitor_t();
topic_monitor_t &topic_monitor_t::principal() {
// Do not attempt to move s_principal to a function-level static, it needs to be accessed from a
// signal handler so it must not be lazily created.
return *s_principal;
}
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
topic_monitor_t::topic_monitor_t() = default;
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
topic_monitor_t::~topic_monitor_t() = default;
void topic_monitor_t::post(topic_t topic) {
// Beware, we may be in a signal handler!
// Atomically update the pending topics.
Use some fancy atomics in topic_monitor The topic monitor is what allows a thread to wait for any of a set of events. Events are identified by a bit in a "pending update" mask. Prior to this fix, post() would atomically set the bit, and if it was newly set, announce the change by unconditionally writing to a self-pipe. Threads could wait for new posts by reading from the pipe. This is less efficient than it could be; in particular if no thread is waiting on the pipe, then the write() is unnecessary. This slows down our signal handler. Change the design in the following way: if a thread is committed to waiting, then it atomically sets the "pending update" mask (now just called status) to a sentinel value STATUS_NEEDS_WAKEUP. Then post() will only write to the self-pipe if it sees that there is a thread waiting. This reduces the number of syscalls. The total effect is hardly noticeable (usually there is a thread waiting) but it will be important for the next commit.
2020-08-20 19:07:49 +00:00
const uint8_t topicbit = topic_to_bit(topic);
// CAS in our bit, capturing the old status value.
status_bits_t oldstatus;
bool cas_success = false;
while (!cas_success) {
oldstatus = status_.load(std::memory_order_relaxed);
// Clear wakeup bit and set our topic bit.
status_bits_t newstatus = oldstatus;
newstatus &= ~STATUS_NEEDS_WAKEUP;
newstatus |= topicbit;
cas_success = status_.compare_exchange_weak(oldstatus, newstatus);
}
// Note that if the STATUS_NEEDS_WAKEUP bit is set, no other bits must be set.
assert(((oldstatus == STATUS_NEEDS_WAKEUP) == bool(oldstatus & STATUS_NEEDS_WAKEUP)) &&
"If STATUS_NEEDS_WAKEUP is set no other bits should be set");
// If the bit was already set, then someone else posted to this topic and nobody has reacted to
// it yet. In that case we're done.
if (oldstatus & topicbit) {
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
return;
}
Use some fancy atomics in topic_monitor The topic monitor is what allows a thread to wait for any of a set of events. Events are identified by a bit in a "pending update" mask. Prior to this fix, post() would atomically set the bit, and if it was newly set, announce the change by unconditionally writing to a self-pipe. Threads could wait for new posts by reading from the pipe. This is less efficient than it could be; in particular if no thread is waiting on the pipe, then the write() is unnecessary. This slows down our signal handler. Change the design in the following way: if a thread is committed to waiting, then it atomically sets the "pending update" mask (now just called status) to a sentinel value STATUS_NEEDS_WAKEUP. Then post() will only write to the self-pipe if it sees that there is a thread waiting. This reduces the number of syscalls. The total effect is hardly noticeable (usually there is a thread waiting) but it will be important for the next commit.
2020-08-20 19:07:49 +00:00
// We set a new bit.
// Check if we should wake up a thread because it was waiting.
if (oldstatus & STATUS_NEEDS_WAKEUP) {
std::atomic_thread_fence(std::memory_order_release);
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
sema_.post();
Use some fancy atomics in topic_monitor The topic monitor is what allows a thread to wait for any of a set of events. Events are identified by a bit in a "pending update" mask. Prior to this fix, post() would atomically set the bit, and if it was newly set, announce the change by unconditionally writing to a self-pipe. Threads could wait for new posts by reading from the pipe. This is less efficient than it could be; in particular if no thread is waiting on the pipe, then the write() is unnecessary. This slows down our signal handler. Change the design in the following way: if a thread is committed to waiting, then it atomically sets the "pending update" mask (now just called status) to a sentinel value STATUS_NEEDS_WAKEUP. Then post() will only write to the self-pipe if it sees that there is a thread waiting. This reduces the number of syscalls. The total effect is hardly noticeable (usually there is a thread waiting) but it will be important for the next commit.
2020-08-20 19:07:49 +00:00
}
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
}
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
generation_list_t topic_monitor_t::updated_gens_in_data(acquired_lock<data_t> &data) {
Add FLOG logging to the topic monitor
2019-05-29 21:20:07 +00:00
// Atomically acquire the pending updates, swapping in 0.
Use some fancy atomics in topic_monitor The topic monitor is what allows a thread to wait for any of a set of events. Events are identified by a bit in a "pending update" mask. Prior to this fix, post() would atomically set the bit, and if it was newly set, announce the change by unconditionally writing to a self-pipe. Threads could wait for new posts by reading from the pipe. This is less efficient than it could be; in particular if no thread is waiting on the pipe, then the write() is unnecessary. This slows down our signal handler. Change the design in the following way: if a thread is committed to waiting, then it atomically sets the "pending update" mask (now just called status) to a sentinel value STATUS_NEEDS_WAKEUP. Then post() will only write to the self-pipe if it sees that there is a thread waiting. This reduces the number of syscalls. The total effect is hardly noticeable (usually there is a thread waiting) but it will be important for the next commit.
2020-08-20 19:07:49 +00:00
// If there are no pending updates (likely) or a thread is waiting, just return.
Add FLOG logging to the topic monitor
2019-05-29 21:20:07 +00:00
// Otherwise CAS in 0 and update our topics.
const auto relaxed = std::memory_order_relaxed;
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
topic_bitmask_t changed_topic_bits;
Add FLOG logging to the topic monitor
2019-05-29 21:20:07 +00:00
bool cas_success;
do {
Use some fancy atomics in topic_monitor The topic monitor is what allows a thread to wait for any of a set of events. Events are identified by a bit in a "pending update" mask. Prior to this fix, post() would atomically set the bit, and if it was newly set, announce the change by unconditionally writing to a self-pipe. Threads could wait for new posts by reading from the pipe. This is less efficient than it could be; in particular if no thread is waiting on the pipe, then the write() is unnecessary. This slows down our signal handler. Change the design in the following way: if a thread is committed to waiting, then it atomically sets the "pending update" mask (now just called status) to a sentinel value STATUS_NEEDS_WAKEUP. Then post() will only write to the self-pipe if it sees that there is a thread waiting. This reduces the number of syscalls. The total effect is hardly noticeable (usually there is a thread waiting) but it will be important for the next commit.
2020-08-20 19:07:49 +00:00
changed_topic_bits = status_.load(relaxed);
if (changed_topic_bits == 0 || changed_topic_bits == STATUS_NEEDS_WAKEUP)
return data->current;
cas_success = status_.compare_exchange_weak(changed_topic_bits, 0);
Add FLOG logging to the topic monitor
2019-05-29 21:20:07 +00:00
} while (!cas_success);
Use some fancy atomics in topic_monitor The topic monitor is what allows a thread to wait for any of a set of events. Events are identified by a bit in a "pending update" mask. Prior to this fix, post() would atomically set the bit, and if it was newly set, announce the change by unconditionally writing to a self-pipe. Threads could wait for new posts by reading from the pipe. This is less efficient than it could be; in particular if no thread is waiting on the pipe, then the write() is unnecessary. This slows down our signal handler. Change the design in the following way: if a thread is committed to waiting, then it atomically sets the "pending update" mask (now just called status) to a sentinel value STATUS_NEEDS_WAKEUP. Then post() will only write to the self-pipe if it sees that there is a thread waiting. This reduces the number of syscalls. The total effect is hardly noticeable (usually there is a thread waiting) but it will be important for the next commit.
2020-08-20 19:07:49 +00:00
assert((changed_topic_bits & STATUS_NEEDS_WAKEUP) == 0 &&
"Thread waiting bit should not be set");
Add FLOG logging to the topic monitor
2019-05-29 21:20:07 +00:00
// Update the current generation with our topics and return it.
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
for (topic_t topic : all_topics()) {
if (changed_topic_bits & topic_to_bit(topic)) {
data->current.at(topic) += 1;
Change C casts to C++ ones Some were kept for compatibility. Found with -Wold-style-cast Signed-off-by: Rosen Penev <rosenp@gmail.com>
2020-04-08 23:56:59 +00:00
FLOG(topic_monitor, "Updating topic", static_cast<int>(topic), "to",
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
data->current.at(topic));
Add FLOG logging to the topic monitor
2019-05-29 21:20:07 +00:00
}
}
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
// Report our change.
data_notifier_.notify_all();
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
return data->current;
Add FLOG logging to the topic monitor
2019-05-29 21:20:07 +00:00
}
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
generation_list_t topic_monitor_t::updated_gens() {
auto data = data_.acquire();
return updated_gens_in_data(data);
}
bool topic_monitor_t::try_update_gens_maybe_becoming_reader(generation_list_t *gens) {
bool become_reader = false;
auto data = data_.acquire();
for (;;) {
// See if the updated gen list has changed. If so we don't need to become the reader.
auto current = updated_gens_in_data(data);
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
FLOG(topic_monitor, "TID", thread_id(), "local ", gens->describe(), ": current",
current.describe());
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
if (*gens != current) {
*gens = current;
break;
}
// The generations haven't changed. Perhaps we become the reader.
Use some fancy atomics in topic_monitor The topic monitor is what allows a thread to wait for any of a set of events. Events are identified by a bit in a "pending update" mask. Prior to this fix, post() would atomically set the bit, and if it was newly set, announce the change by unconditionally writing to a self-pipe. Threads could wait for new posts by reading from the pipe. This is less efficient than it could be; in particular if no thread is waiting on the pipe, then the write() is unnecessary. This slows down our signal handler. Change the design in the following way: if a thread is committed to waiting, then it atomically sets the "pending update" mask (now just called status) to a sentinel value STATUS_NEEDS_WAKEUP. Then post() will only write to the self-pipe if it sees that there is a thread waiting. This reduces the number of syscalls. The total effect is hardly noticeable (usually there is a thread waiting) but it will be important for the next commit.
2020-08-20 19:07:49 +00:00
// Note we still hold the lock, so this cannot race with any other thread becoming the
// reader.
if (data->has_reader) {
// We already have a reader, wait for it to notify us and loop again.
data_notifier_.wait(data.get_lock());
continue;
} else {
// We will try to become the reader.
// Reader bit should not be set in this case.
assert((status_.load() & STATUS_NEEDS_WAKEUP) == 0 && "No thread should be waiting");
// Try becoming the reader by marking the reader bit.
status_bits_t expected_old = 0;
if (!status_.compare_exchange_strong(expected_old, STATUS_NEEDS_WAKEUP)) {
// We failed to become the reader, perhaps because another topic post just arrived.
// Loop again.
continue;
}
// We successfully did a CAS from 0 -> STATUS_NEEDS_WAKEUP.
// Now any successive topic post must signal us.
FLOG(topic_monitor, "TID", thread_id(), "becoming reader");
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
become_reader = true;
data->has_reader = true;
break;
}
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
}
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
return become_reader;
}
generation_list_t topic_monitor_t::await_gens(const generation_list_t &input_gens) {
generation_list_t gens = input_gens;
while (gens == input_gens) {
bool become_reader = try_update_gens_maybe_becoming_reader(&gens);
if (become_reader) {
// Now we are the reader. Read from the pipe, and then update with any changes.
// Note we no longer hold the lock.
assert(gens == input_gens &&
"Generations should not have changed if we are the reader.");
topic_monitor to use binary semaphore instead of self-pipe With the prior commit, the topic_monitor only writes to the pipe if a thread is known to be waiting. This is effectively a binary semaphore, and on systems that support anon semaphores (yes Linux, but not Mac) we can use them. These are more efficient than self-pipes. We add a binary_semaphore_t class which uses sem_t if sem_init succeeds, and a self-pipe if it fails. On Linux the seq_echo benchmark (run 1024 times) goes from 12.40 seconds to 11.59 seconds, about an 11% improvement.
2020-08-20 20:57:51 +00:00
// Wait to be woken up.
sema_.wait();
// We are finished waiting. We must stop being the reader, and post on the condition
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
// variable to wake up any other threads waiting for us to finish reading.
auto data = data_.acquire();
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
gens = data->current;
FLOG(topic_monitor, "TID", thread_id(), "local", input_gens.describe(),
"read() complete, current is", gens.describe());
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
assert(data->has_reader && "We should be the reader");
data->has_reader = false;
data_notifier_.notify_all();
}
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
}
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
return gens;
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
}
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
bool topic_monitor_t::check(generation_list_t *gens, bool wait) {
if (!gens->any_valid()) return false;
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
generation_list_t current = updated_gens();
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
bool changed = false;
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
for (;;) {
// Load the topic list and see if anything has changed.
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
for (topic_t topic : all_topics()) {
if (gens->is_valid(topic)) {
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
assert(gens->at(topic) <= current.at(topic) &&
"Incoming gen count exceeded published count");
if (gens->at(topic) < current.at(topic)) {
gens->at(topic) = current.at(topic);
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
changed = true;
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
}
}
}
// If we're not waiting, or something changed, then we're done.
Simplify topic monitoring The topic monitor allows a client to wait for multiple events, e.g. sigchld or an internal process exit. Prior to this change a client had to specify the list of generations and the list of topics they are interested in. Simplify this to just the list of generations, with a max-value generation meaning the topic is not interesting. Also remove the use of enum_set and enum_array, it was too complex for what it offered.
2020-08-07 02:00:53 +00:00
if (!wait || changed) {
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
break;
}
Correct a race in topic monitor This fixes a race condition in the topic monitor. A thread may decide to enter the wait queue, but before it does the generation list changes, and so our thread will wait forever, resulting in a hang. It also simplifies the implementation of the topic monitor considerably; on reflection the whole "metagen" thing isn't providing any value and we should just compare generations directly. In the new design, we have a lock-protected list of current generations, along with a boolean as to whether someone is reading from the pipe. The reader (only one at a time) is responsible for broadcasting notifications via a condition variable.
2019-05-31 16:13:21 +00:00
// Wait until our gens change.
current = await_gens(current);
Introduce topic monitoring topic_monitor allows for querying changes posted to one or more topics, initially sigchld. This will eventually replace the waitpid logic in process_mark_finished_children(). Comment from the new header: Topic monitoring support. Topics are conceptually "a thing that can happen." For example, delivery of a SIGINT, a child process exits, etc. It is possible to post to a topic, which means that that thing happened. Associated with each topic is a current generation, which is a 64 bit value. When you query a topic, you get back a generation. If on the next query the generation has increased, then it indicates someone posted to the topic. For example, if you are monitoring a child process, you can query the sigchld topic. If it has increased since your last query, it is possible that your child process has exited. Topic postings may be coalesced. That is there may be two posts to a given topic, yet the generation only increases by 1. The only guarantee is that after a topic post, the current generation value is larger than any value previously queried. Tying this all together is the topic_monitor_t. This provides the current topic generations, and also provides the ability to perform a blocking wait for any topic to change in a particular topic set. This is the real power of topics: you can wait for a sigchld signal OR a thread exit.
2019-02-02 23:39:04 +00:00
}
return changed;
}
Reference in a new issue Copy permalink