Our queue<T> is a convenient mechanism for passing data between a producer
fiber (a set of consecutive continuations) and a consumer fiber.
However, queue<T> is difficult to use *correctly*. The biggest problem is
how to handle premature stopping: What if one of the two fibers (the reader
or the writer) stops prematurely, and will never read or write any more?
When queue<T> is used naively, the other fiber will just hang indefinitely
while it waits to read from the empty queue, or write to the full queue.
The solution proposed in this patch is a new pipe mechanism, implemented
internally over a queue. pipe<T>() returns two separate objects - a pipe
reader, and a pipe writer. Typically each object is std::move()ed into a
different fiber. When a fiber stops and its captured variables are destroyed,
one end of the pipe is destroyed, and that causes the other end's operations
to return immediately (if the other end was already blocked, it will resume
immediately, and return an exceptions). This behavior is analogous to
Unix's EOF or broken-pipe behavior.
Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
Otherwise tester may crash if _instances destructor is called when thread
responsible for the allocation (which tester spawned to run seastar in)
no longer running.
There are many situations in which we would like to make sure a directory
exists. We can do that by creating the directory we want, and just ignoring
the relevant error.
It is a lot of code though, and I believe it is an idiom common enough to exist
on its own.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
wait() with timeout takes reference to an entry, but when
circular_buffer is resized it may be moved, so freed instance will be
accessed on timeout. Fix it by using std::list instead.
When using boost --output-format=XML flag for jenkins the output file is
garbled - it seems that some output is lost. To try and overcome this
changed impl to use a temporay file instead of a PIPE.
Signed-off-by: Shlomi Livne <shlomi@cloudius-systems.com>
The thread switching code assumed that we will always switch out of a
thread due to being blocked on an unavailable future. This allows
the core to store the blocked thread's context in the synthetic
continuation chained to that future (which switched back to that thread).
That assumption failed in one place: when we create a thread from within a
thread. In that case we switch to the new thread immediately, but forget
all about the old thread. We never come back to the old thread, and anything
that depends on it hangs.
Fix by creating a linked list of active thread contexts. These are all
threads that have been "preempted" by the act of creating a new thread,
terminated by the main, unthreaded, reactor context. This gives us a place
to store those threads and we come back to them and continue where we left
off.
Reported by Pekka.
We don't use this module and it's compilation is broken in DPDK 2.0.0
against Linux kernels 4.0.x.
Signed-off-by: Vlad Zolotarov <vladz@cloudius-systems.com>
