It’s common when building systems to periodically perform some action in the future. Send a heartbeat message, run a garbage collection task, blink a light. In threaded execution models a simple approach is to have a worker thread perform an action then sleep for some period. However, in a system like Seastar there are no threads to put to sleep (although technically you could create a looping fiber with a call to seastar::sleep).
There are a few common scenarios that arise when using Seastar that require
controlling the lifetime of resources referenced by asynchronous fibers (e.g.
background fibers). In each of these cases it is generally necessary to wait
until all possible references have been released before destroying a resource.
This situation arises often enough that Seastar provides the
utility which implements an easy-to-use pattern for solving the problem.
In a previous post I discussed Seastar’s shared pointer type for managing a shared resource using reference counting. In this post I am going to discuss another smart pointer type provided by Seastar called a weak pointer. A weak pointer is similar to a shared pointer, but the twist is that the pointer does not have any influence over the lifetime of the resource it references, and as a result, may be invalidated at any moment!
In this post we’ll take a look at Seastar’s
temporary_buffer utility for efficiently managing contiguous regions of memory. Many Seastar interfaces pass around data using this utility, and applications often use the
temporary_buffer as a building block for higher level memory management abstractions.
In this post we are going to discuss a Seastar utility
seastar::deleter that is used for managing the lifetime of data. In
many ways a
deleter can be thought of as a unified approach to RAII for both
raw memory pointers and objects, but it also adds other goodies like
reference counting and deleter chaining.