Changeset 207

Timestamp:

07/13/06 08:46:26 (2 years ago)

Author:

blackhedd

Message:

Added deferred operations

Files:

• version_0/lib/eventmachine.rb (modified) (3 diffs)

version_0/lib/eventmachine.rb

@@ -1 +1 @@
-# $Id$
-#
-2
+1
-# Date:: 8 Apr 2006
-# 
@@ -133 +133 @@
-module EventMachine
-
-5.4
+6.0
-
-  # EventMachine::run initializes and runs an event loop.
@@ -597 +597 @@
-    c
-  end
+
+
+
+
+  module DeferredTrigger # :nodoc:
+    def receive_data str
+      EventMachine.run_deferred_callbacks
+    end
+  end
+
+
+  def self::run_deferred_callbacks # :nodoc:
+    until @resultqueue.empty?
+      result,cback = @resultqueue.pop
+      cback.call result if cback
+    end
+  end
+
+  # #defer is for integrating blocking operations into EventMachine's control flow.
+  # Call #defer with one or two blocks, as shown below (the second block is <i>optional</i>):
+  #  
+  #  operation = proc {
+  #    # perform a long-running operation here, such as a database query.
+  #    "result" # as usual, the last expression evaluated in the block will be the return value.
+  #  }
+  #  callback = proc {|result|
+  #    # do something with result here, such as send it back to a network client.
+  #  }
+  #
+  #  EventMachine.defer( operation, callback )
+  #  
+  # The action of #defer is to take the block specified in the first parameter (the "operation")
+  # and schedule it for asynchronous execution on an internal thread pool maintained by EventMachine.
+  # When the operation completes, it will pass the result computed by the block (if any)
+  # back to the EventMachine reactor. Then, EventMachine calls the block specified in the
+  # second parameter to #defer (the "callback"), as part of its normal, synchronous
+  # event handling loop. The result computed by the operation block is passed as a parameter
+  # to the callback. You may omit the callback parameter if you don't need to execute any code
+  # after the operation completes.
+  #
+  # <i>Caveats:</i>
+  # This is a <b>provisional</b> implementation and is subject to change.
+  # Note carefully that the code in your deferred operation will be executed on a separate
+  # thread from the main EventMachine processing and all other Ruby threads that may exist in
+  # your program. Also, multiple deferred operations may be running at once! Therefore, you
+  # are responsible for ensuring that your operation code is threadsafe. [Need more explanation
+  # and examples.]
+  # Don't write a deferred operation that will block forever. If so, the current implementation will
+  # not detect the problem, and the thread will never be returned to the pool. EventMachine limits
+  # the number of threads in its pool, so if you do this enough times, your subsequent deferred
+  # operations won't get a chance to run. [We might put in a timer to detect this problem.]
+  #
+  def self::defer op, callback = nil
+    unless @threadqueue
+
+      start_server "127.0.0.1", 29999, DeferredTrigger
+      @deferred_trigger = connect "127.0.0.1", 29999
+
+      require 'thread'
+      @threadqueue = Queue.new
+      @resultqueue = Queue.new
+      20.times {|ix|
+        Thread.new {
+          my_ix = ix
+          loop {
+            op,cback = @threadqueue.pop
+            result = op.call
+            @resultqueue << [result, cback]
+            @deferred_trigger.send_data "."
+          }
+        }
+      }
+    end
+
+    @threadqueue << [op,callback]
+  end
+
-
-