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.
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.)