RubyDNS 0.7.0 - Using Fiber for improved DSL

Detlef_R · February 2, 2014, 3:28pm

Hi Everyone,

I wouldn’t normally share an incremental release, but I thought that the
way I used Fibers in the latest version of RubyDNS might be interesting
to
others.

Previously, RubyDNS used EventMachine deferrables for managing
“sequential”
event based processing. The code to wire up sequential events was fairly
unintuitive and for clients using the RubyDNS DSL, it was even more
buggy/confusing.

Enter Fibers. Now deferred and sequential processing follow the same
pathway. For each transaction (incoming DNS request) a Fiber is created.
Once the Fiber terminates, the result is returned to the client. By
default, the execution is linear, but if the user wants to pass the DNS
request upstream, the fiber is suspended until the request is done (or
fails).

When I first started looking at fibers, I didn’t realise how powerful
they
are because they avoid tangled event driven code for the user and for
the
most part hide the implementation details regarding what might take time
to
complete. Now, I feel confident that RubyDNS has improved both the
intuitive nature of the DSL, and also the actual implementation is
easier
to follow/test.

For more details, please see the RubyDNS project page:
RubyDNS or browse the latest
source code:
https://github.com/ioquatix/rubydns/blob/master/lib/rubydns/server.rb#L75-L94

Here is the code, pre-fiberization:

github.com

socketry/rubydns/blob/0505d52f6078919eceb5e0599f8b225f9a54dffb/lib/rubydns/server.rb#L189-L238


      
          			# 1/ This chain contains a reverse list of question lambdas.
          			chain = []
          
          
			# 4/ Finally, the answer is given back to the calling block:
          			chain << lambda do
          				@logger.debug "Passing answer back to caller..."
          				yield answer
          			end
          
          
			# There may be multiple questions per query
          			query.question.reverse.each do |question, resource_class|
          				next_link = chain.last
          
          
				chain << lambda do
          					@logger.debug "Processing question #{question} #{resource_class}..."
          
          
					transaction = Transaction.new(self, query, question, resource_class, answer, options)
          					
          					# Call the next link in the chain:
          					transaction.callback do

This file has been truncated. show original

Fiber is a really nice feature, looking forward to using it in more
projects.

Kind regards,
Samuel

Samuel_W · February 4, 2014, 9:19pm

On 02/02/2014 06:27 AM, Samuel W. wrote:

For more details, please see the RubyDNS project page:
RubyDNS or browse the latest
source code:
https://github.com/ioquatix/rubydns/blob/master/lib/rubydns/server.rb#L75-L94

Here is the code, pre-fiberization:

github.com

socketry/rubydns/blob/0505d52f6078919eceb5e0599f8b225f9a54dffb/lib/rubydns/server.rb#L189-L238


      
          			# 1/ This chain contains a reverse list of question lambdas.
          			chain = []
          
          
			# 4/ Finally, the answer is given back to the calling block:
          			chain << lambda do
          				@logger.debug "Passing answer back to caller..."
          				yield answer
          			end
          
          
			# There may be multiple questions per query
          			query.question.reverse.each do |question, resource_class|
          				next_link = chain.last
          
          
				chain << lambda do
          					@logger.debug "Processing question #{question} #{resource_class}..."
          
          
					transaction = Transaction.new(self, query, question, resource_class, answer, options)
          					
          					# Call the next link in the chain:
          					transaction.callback do

This file has been truncated. show original

Very nice. So, next time I see a chain of lambdas, I’ll try to replace
it with a fiber.

Very OT, but it reminded me of this example from SimPy:

http://simpy.readthedocs.org/en/latest/examples/gas_station_refuel.html

This uses (python) generators to preserve the imperative flow of an
actor, while also allowing interaction with the simulation.
(Python’s generators seem to be more or less fibers, but I know little
python.)

Samuel_W · February 4, 2014, 10:03pm

Be sure to check out Celluloid if you’re interested in these sorts of
patterns:

On Tue, Feb 4, 2014 at 12:18 PM, Joel VanderWerf