Totally confused on the concept of promise in dea_ng

[Hongliang Sun]

Hi, guys:

         Another question to ask you. And it is about the Promise concept in promise.rb in dea_ng.

         When I was studying the source code of dea_ng, I found that dea_ng handles a lot of jobs by Promise and Promise is implemented by Fiber in ruby to achieve high performance of concurrency.  As I am not very familiar with the Fiber, I can not quite understand the entire implementation of Promise. However I still have few understandings below, maybe totally incorrect:

        1.Promise is designed to be a some-like scheduler to handle waiting jobs. Since the def resume makes all waiting jobs of this promise resume

     def resume(result)

      # Set result once

      unless @result

        @result = result

        @elapsed_time = Time.now - @start_time

        # Resume waiting fibers

        waiting, @waiting = @waiting, []

        waiting.each(&:resume)

      end

            2. And in def run_in_parallel and run_serially, Promise seems to make the jobs run in correct order.

 

            3.in def deliver, Promise will call resume to run the waiting queue.

            4.in def resolve, Promise calls def run to create a fiber to run the block of original promise and calls def wait to push current fiber into waiting queue.

            No matter what I can think of about the concept Promise, I can not support my own view in theory. For example, I am still confused on two examples below:

Promise.new do |p|
        request = ::Warden::Protocol::StopRequest.new
        request.handle = container.handle
        container.call(:stop, request)

        p.deliver
      end

promise = Promise.new do
        logger.info "task.destroying"
        promise_destroy.resolve
        promise.deliver
      end

I know lots of people are good at ruby and fiber. Maybe you can give me some help, or some guidance on the internet I need to read first.

Thanks.

Best Regard

Hongliang Sun

            

           

[Michael Fraenkel]

You aren't confused.
I went through the same confusions a few months ago and started to play with examples to better understand Promises.

Outside of run_in_parallel and run_serially, promises tend to be best effort is how I view it.  If a "nested" promise completes before its parent, its evaluation can bubble up a failure.  However, if it does not deliver/fail, the result is lost.

You will also notice that there is Promise.resolve() as another mechanism to create what I view as an async promise.  However since its all on Fibers, the result can come back to the original caller immediately thereby making it look synchronous.