Jesse’s code implements a single producer, multiple consumer queue using MagLev persistence and plain old Ruby objects. Here is the producer:

Maglev.abort_transaction Maglev::PERSISTENT_ROOT[:q] ||= [] 20.times do |t| Maglev::PERSISTENT_ROOT[:q] << Proc.new { sleep 1; puts "job ##{t}" } end Maglev.commit_transaction

Maglev::PERSISTENT_ROOT is a Hash that is persistent (i.e., it and its contents are saved in the MagLev repository, and are visible to all MagLev VMs that connect to the repository.

Because MagLev implements Persistence by Reachability, the array that is assigned to PERSISTENT_ROOT[:q] , and the contents of that array will also be persisted to the repository. So, when Jesse puts twenty Proc objects into the queue, and commits them, they will be available to any worker in any MagLev VM connected to the same repository. Here’s the worker (consumer) code:

work = "let's do something" while work do begin Maglev.abort_transaction work = Maglev::PERSISTENT_ROOT[:q].shift Maglev.commit_transaction work.call if work rescue Maglev::CommitFailedException puts "Dang, someone hijacked my job... gonna grab another." redo end end

Workers spend their dreary lives in the confines of a loop, endlessly pulling jobs off of the queue and executing them. The unique aspect MagLev brings is that these workers can be in a different VM and on a different node from the VM that created the proc. The system is coordinated using MagLev transactions.

The worker begins his day with Maglev.abort_transaction . This creates a new transactional context, and gives it the latest version of the job queue. The worker then pulls the next job off of the queue:

work = Maglev::PERSISTENT_ROOT[:q].shift

commits the new state of the queue:

Maglev.commit_transaction

and gets down to work:

work.call if work