Fiber Pooling With NeverBlock

As mentioned in my earlier introduction about fibers I will be talking today about the fiber pooling features that are implemented as part of the NeverBlock library.

The fiber pool is implemented as the NeverBlock::Pool::FiberPool class. The interface is super easy, with only one public method spawn that is. Here’s an example

# create a pool of 30 fibers pool = NB::Pool::FiberPool.new(30) # start spawinig fibers for use pool.spawn do # do something useful in your fiber end

The spawn method take only one argument, which is a code block to be run as a fiber. The spawned fiber will resume immediately (that is, if the pool managed to find us a free fiber immediately).

How does the pooling work then?

Initially when you create a new pool all the fibers will be created in advance (we can consider a lazy generation option later). They are all stored in an array and the pool waits for requests. Once the method spawn is called the pool checks the fibers array, if it can find any, it takes a fiber out of the array and resumes it with the block as the parameter. If no fibers are present at the moment the block is put in a queue for later processing.

Here’s how the spawn method is written:

def spawn(&block) if fiber = @fibers.shift # check if there is an available fiber fiber.resume(block) # yes there is one, resume it with the block as a parameter else # sadly no fibers are available now @queue << block # wait in a queue end end

Once the fibers are first initialized they are given a non-ending loop that attempts to run blocks in the following manner:

# this is the pool initialization method def initialize(size=50) # default number of fibers in the pool is 50 size.times do f = Fiber.new do |block| loop do # loop forever # call our current block and pause waiting for another block to be # passed to us and be called as well block = Fiber.yield block.call end end @fibers << f # add the fiber to the list of available fibers end end

Whenever you call resume on such a fiber and pass a block, the block will be called and when done the fiber will yield control back again.

But how will the fiber ever become avialable again in the @fibers array? glad you noticed. The actual implementation is a little different

# again this is the pool initialization method def initialize(size=50) # default number of fibers in the pool is 50 size.times do f = Fiber.new do |block| loop do # loop forever # call our current block block.call # if there are any blocks in the queue fetch one unless @queue.empty? # queue is not empty # grab a block # and it will be # called in # the new iteration block = queue.shift else # queue is empty # put the fiber in the fibers list # and yield back control # waiting for a new block block = Fiber.yield @fibers << Fiber.current end end end @fibers << f # add the fiber to the list of available fibers end end

The only caveat here is that our spawn method no longer returns the value of running the fiber. But that was the case with queued blocks any way so it’s no big deal.

While fibers are cheaper than threads, they still come at a memory and performance cost. Using a pool makes sure your memory usage is controlled and that not too many transient fibers are created. Coming up for this pool is the ability to grow and shrink the fiber count based on usage. By defining minimum and maximum sizes rather than a single size the pool should be able to move between those values to accommodate different work loads.