standard-procedure-async 0.1.0 → 0.1.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: b92c0e8440b6f2ad4b0c95cc83ac562ece4124490f15982f1d6531efec3ca2b1
-  data.tar.gz: ba0100a22ccbf8c572489111b841bdee403347e2f3a65172b8584594ebd026e5
+  metadata.gz: 7c712b9a4a30138eb2c834422df444d22da7fbb16da26de1c1ec81db7cf15985
+  data.tar.gz: 71dbabb9e071adb19146e17a275daaad05b0c9f242843b3d957908087f604a91
 SHA512:
-  metadata.gz: ec6d3846f51149189ae18dffbf38af10cbb9c317ac9b546b1e336b726219d040b7b0d5fab65dd4a33c1be079ad093703947236c46ce1345af0f33cc5474bb50d
-  data.tar.gz: fb99264092314bad0f9c4c1e7d1061e2530456bf59b409eadbbe6f5f4a216ad69d71a5abd2fd3a74c4d0c1de0d9fa4f50b7f2053259de9435bfd3e9f7eb34fc8
+  metadata.gz: d84213a0def468819fbd0f63bc42d10a483b13790e1e3ee632b72d63d2d2d9438df2c7a3a586b6acbedba07ceaf8794b999c33cd53df4fb166cf0f5e5f998289
+  data.tar.gz: 3972be625613fa325b92273d594f0e9c213fa4675e03181c39d60e334251f3fea7e6d369a9335dc639994aa182de8ead6785be04d011d21186c56b08badfc9fb

data/CHANGELOG.md

@@ -1,4 +1,10 @@
-## [Unreleased]
+## [0.1.2] - 2023-05-31
+
+- Added a timeout to `StandardProcedure::Async::Actor::Message` to prevent indefinite deadlocks. 
+
+## [0.1.1] - 2023-05-31
+
+- Changed the namespace from Standard::Procedure to StandardProcedure
 
 ## [0.1.0] - 2023-05-30
 

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    standard-procedure-async (0.1.0)
+    standard-procedure-async (0.1.2)
       concurrent-ruby (>= 1.0)
 
 GEM

data/README.md

@@ -1,4 +1,4 @@
-# Standard::Procedure::Async
+# StandardProcedure::Async
 
 ## The Actor model
 
@@ -8,7 +8,11 @@ The actual implementation does not use a thread-per-object as that could get ver
 
 ## Why does this gem exist?
 
-Two reasons.  
+The short answer: 
+
+Because you can't use concurrent-ruby's Async mixin inside a Rails app.  On top of that, I wanted to change its syntax a little bit to match how it's done in Javascript.  
+
+The long answer:
 
 Concurrent-ruby has a simple implementation of this model, using the [Async](https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/Async.html) mixin.  However, Concurrent::Async uses [IVar](https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/IVar.html)s which are now deprecated.  
 
@@ -16,24 +20,24 @@ In addition, while concurrent-ruby is an excellent library, it does not work wel
 
 Finally, using the actor model is infectious.  If you mark a public method as asynchronous, in order to be safe, you have to mark them all as asynchronous.  Concurrent::Async's syntax relies on the caller using `@my_object.async.my_method` which means that it is easy to forget and miss an asynchronous call.  Which in turn will result in inconsistent behaviour and hard to trace bugs.  
 
-So [Standard::Procedure::Async::Actor](https://github.com/standard-procedure/async/blob/main/lib/standard/procedure/async/actor.rb) replaces the IVars with a mix of Futures and MVars.  The MVar is used to transfer the return values of any methods back to the calling thread and the Future is used to do the work in a separate thread.  
+So [StandardProcedure::Async::Actor](https://github.com/standard-procedure/async/blob/main/lib/standard_procedure/async/actor.rb) replaces the IVars with a mix of Futures and [MVar](https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/MVar.html)s.  The MVar is used to transfer the return values of any methods back to the calling thread and the Future is used to do the work in a separate thread.  
 
-In addition, if you are in a Ruby on Rails project, Standard::Procedure::Async uses [Luiz Kowalski](https://github.com/luizkowalski)'s [concurrent_rails](https://github.com/luizkowalski/concurrent_rails) gem.  This is a layer above concurrent-ruby's Futures that ensure any future code is run within the Rails Executor.  
+In addition, if you are in a Ruby on Rails project, StandardProcedure::Async uses [Luiz Kowalski](https://github.com/luizkowalski)'s [concurrent_rails](https://github.com/luizkowalski/concurrent_rails) gem.  This is a layer above concurrent-ruby's Futures that ensure any future code is run within the Rails Executor.  
 
 Finally, instead of relying on the caller to call `async` on asynchronous methods, we define the asynchronous methods on the class itself with the `async` definition.  The caller simply uses `@my_object.my_method` and it will always be run safely in an alternate thread.  There is also an implementation of `await`, making it easy to resolve the results of your method calls.  
 
 ## Adding `async` and `await` capabilities to ruby objects
 
-Instead of defining methods on your class with ruby's `def` keyword, include the [Standard::Procedure::Async::Actor](https://github.com/standard-procedure/async/blob/main/lib/standard/procedure/async/actor.rb) module and use the `async` class method.  
+Instead of defining methods on your class with ruby's `def` keyword, include the [StandardProcedure::Async::Actor](https://github.com/standard-procedure/async/blob/main/lib/standard_procedure/async/actor.rb) module and use the `async` class method.  
 
-When you call an asynchronous method, it immediately returns an internal message object.  If you don't care about the return value from the method, you can discard this object immediately.  But if you do need the return value, you can call `value` on this message object - and your thread will then wait until the return value is ready.  Alternatively, you can use `await`, effectively turning your asynchronous method into a synchronous one.  
+When you call an asynchronous method, it immediately returns an internal message object.  If you don't care about the return value from the method, you can discard this object immediately.  But if you do need the return value, you can call `value` on this message object - and your thread will then block until the return value is ready.  Alternatively, you can use `await`, effectively turning your asynchronous method into a synchronous one.  See the note below about using `await` or `value` if you are calling a method from inside an actor - in short, be careful.  
 
-An added bonus (or negative, depending upon your point of view) is that this syntax is very similar to Javascript's async/await pairing, which similarly marks out asychronous function calls and waits until any Promises are ready to return their values.  
+An added bonus (or negative, depending upon your point of view) is that this syntax is very similar to Javascript's async/await pairing, which marks out asychronous function calls and waits until any [Promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) are ready to return their values.  
 
 Example usage:
 ```ruby
 class MyObject 
-  include Standard::Procedure::Async::Actor 
+  include StandardProcedure::Async::Actor 
 
   def initialize name 
     @name = name 
@@ -69,15 +73,20 @@ end
 
 @my_object = MyObject.new "George"
 
+# Getting started
+puts @my_object.report_status # => internal message object
+puts @my_object.report_status.value # => :idle
+puts await { @my_object.report_status } # => :idle
 puts await { @my_object.greet } # => "Hello George"
+# Do some actual work
 await { @my_object.rename "Ringo" }
 puts await { @my_object.greet } # => "Hello Ringo"
 @my_object.rename "Paul" # Note: we didn't use await here - we'll talk about that later
 puts await { @my_object.greet } # => "Hello Paul"
-
+# Do something a bit more complex
 @initial_status = @my_object.do_some_long_running_task 
-puts @initial_status # => a internal message object
-puts @initial_status.value # => :in_progress
+puts await { @initial_status } # => :in_progress
+# *drums fingers* *sips from cup of tea*
 sleep 11
 @final_status = await { @my_object.report_status }
 puts @final_status # => :done
@@ -90,13 +99,21 @@ When defining `MyObject`, we use `async` instead of `def` for each method.  For
 
 ### Awaiting the results from those methods
 
-The asynchronous wrapper always returns an object containing a [Concurrent::MVar](https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/MVar.html) which is empty until the actor has completed its work.  
+The asynchronous wrapper always returns a internal message object that contains a [Concurrent::MVar](https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent/MVar.html).  The MVar is empty until the actor has completed its work but if you need the return value from the method, there are two ways to access it.    
+
+You can call `value` on the returned message.  
+
+Or you can use the `await` method (which is just a fancy wrapper around `value`).  
+
+In both cases the calling thread will block until the value is returned.  
 
-If you need the return value from the method, there are two ways to access it.  
+In the example above, you can see how this works. 
 
-You can call `value` on the returned object, or you can use the `await` method (which is just a fancy wrapper around `value`).  In both cases the calling thread will block until the value is returned.  In the example above, you can see what happens if you use neither of these methods - `puts @initial_status` returns the internal message object itself, not any meaningful information.  The next line then calls `@initial_status.value` to wait until the return value is generated.  
+- `puts @my_object.report_status` returns the internal message object itself, not any meaningful information.  
+- `puts @my_object.report_status.value` blocks until the `report_status` method has completed and gives you the return value.
+- `puts await { @my_object.report_status }` is just a fancier (and potentially more readable and explicit) way of doing the same thing
 
-### The sequence of asynchronous calls
+### The strict sequencing of asynchronous calls
 
 In the example above there is the following code:
 
@@ -104,11 +121,13 @@ In the example above there is the following code:
 @my_object.rename "Paul"
 puts await { @my_object.greet } # => "Hello Paul"
 ```
-The call to `rename` is asynchronous, so you may expect that sometimes the following call to `greet` would return "Hello Paul" and other times it would return "Hello Ringo" (the previous value) - depending on the timing of the two calls.  
+The call to `rename` is asynchronous and we call `greet` immediately afterwards.  You may expect that the result from `greet` would not be deterministic.  If `rename` takes a long time to complete it may or may not have finished before we get to the next line of code.  Does that mean that `greet` could return "Hello Ringo" or "Hello Paul" depending on timing?  
 
-However, it will _always_ return "Hello Paul".  
+No - the call to `greet` will _always_ return "Hello Paul".  
 
-This is because internally, the actor queues all method calls.  So even if the call to `rename` takes a long time to complete, the subsequent call to `greet` will not start until `rename` has finished.  
+This is because internally, the actor queues all asynchronous method calls.  
+
+The call to `rename` is added to the queue, then a future starts to process it.  The subsequent call to `greet` is added to the queue and will not begin until the call to `rename` has completed.  
 
 Another example of the same behaviour is in `do_some_long_running_task`:
 
@@ -122,13 +141,30 @@ Another example of the same behaviour is in `do_some_long_running_task`:
 
 When `@my_object.do_some_long_running_task` is called, the message `do_some_long_running_task` is added to the queue.  
 
-When the queue starts processing that message, `_do_some_long_running_task` (the implementation of the method) changes the status to :in_progress, then adds `do_part_two_of_the_long_running_task` to the message queue.  This second message will _not_ start processing immediately as it is behind the unfinished `do_some_long_running_task`.  `_do_some_long_running_task` returns the value of status (which is still :in_progress) and completes, which allows the next message on the queue to start.  And that next message is probably `do_part_two_of_the_long_running_task` - but it might not be, as other threads may have got there first.  
+When the queue starts processing that message, `_do_some_long_running_task` (the implementation of the method) changes the status to :in_progress, then adds `do_part_two_of_the_long_running_task` to the message queue.  This second message will _not_ start processing immediately as it is behind the unfinished `do_some_long_running_task`.  Eventually `_do_some_long_running_task` returns the value of status (which is still :in_progress) and completes, which allows the next message on the queue to start.  And that next message is probably `do_part_two_of_the_long_running_task` - but, this being concurrent programming, it might not be (as another thread may have put a different message onto the queue first). 
+
+This queueing has an important implication.  
+
+If you are within an actor class, you can happily call async methods on other objects and `await` the results - because each actor has its own independent queue.  But if you are calling your own methods, you must **never** call `await` (or call `value` on the returned message object).  
+
+Picture this: 
+- Your actor has two `async` methods - `start_processing` and `do_complicated_calculation`
+- The main thread calls `start_processing` - so a message gets added to the head of the queue.  
+- The actor's internal thread starts working on the message at the head of the queue, and `_start_processing` (the actual implementation) is called.
+- Within `_start_processing` your actor calls `do_complicated_calculation`.  This adds a message to the second position in the queue, ready to start working after `_start_processing` has completed.  The message object itself is returned to `_start_processing`.  
+- Within `_start_processing` you call `value` to extract the actual return value from `do_complicated_calculation`.  This then blocks the actor's thread, while it waits for the value to be calculated.  
+- But the message for `do_complicated_calculation` is second in the queue and won't be called until `_start_processing` has completed.  And `_start_processing` won't complete, as it is now blocked until `_do_complicated_calculation` has finished.  
+- Your actor is now deadlocked and will not be able to do any more work.  
+
+To avoid this, if you ever need the return value from an internal `async` method, always call the implementation method:  `_do_complicated_calculation` instead of `do_complicated_calculation`.  This does not put anything on the queue and proceeds as a normal method call.  
+
+As a fail-safe, any calls to `value` will also time-out after 30 seconds, returning Concurrent::MVar::TIMEOUT.  If you need to override the timeout value you can use `message.value(timeout: value_in_seconds)`.  
 
 ### The rules of using actors
 
-- If you make a public method asynchronous, you need to make _all_ public methods asynchronous.  You cannot mix and match asynchronous and synchronous usage. The simplest way to comply is to make all your public methods as `async` and your protected and private methods as synchronous.  If you have to call an async method on `self` use the internal implementation (which starts with `_`).
-- Never make internal instance variables directly accessible without an asynchronous method call.  Do not use `attr_reader` or `attr_accessor` -  these will bypass the internal queue and you may get inconsistent results from the actor.  For the same reason, never update internal variables outside of an asynchronous call.  
-- When an object is calling its own internal methods, never use `await` or `value` as this will cause your actor to block indefinitely.  If you don't care about the return value or if it does not matter when the method starts and finishes, call the asynchronous method.  If you need the return value or need to be sure that the method runs immediately then use the internal implementation - `_rename` instead of `rename`.
+- If you make a public method asynchronous, you need to make _all_ public methods asynchronous.  You cannot mix and match asynchronous and synchronous usage. The simplest way to comply is to make all your public methods as `async` and your protected and private methods as synchronous.  
+- Never make internal instance variables directly accessible without an asynchronous method call.  Do not use `attr_reader` or `attr_accessor` -  these will bypass the internal queue and you may get inconsistent results from the actor.  For the same reason, never update internal variables outside of an asynchronous call.  In Object-Oriented terms, the doctrine is "Tell, don't Ask": tell your objects what you want them to do, instead of asking them for information about themselves.  
+- When an object is calling its own internal methods, never use `await` or `value` as this will cause your actor to block indefinitely (actually, they will time out after 30s).  If you don't care about the return value or if it does not matter when the method starts and finishes, call the asynchronous method.  If you need the return value or need to be sure that the method runs immediately then use the internal implementation - `_my_method` instead of `my_method`.
 - Avoid class variables.  These are effectively global variables that are accessible without any locking around them, so you could get inconsistent results.  If you must have class variables, intialize them on startup and if they are mutable, use concurrent-ruby's thread-safe objects.  
 
 ## Making Rails work with Concurrent-Ruby

data/lib/{standard/procedure → standard_procedure}/async/actor.rb

@@ -4,7 +4,7 @@ require "concurrent/array"
 require "concurrent/mvar"
 require "concurrent/immutable_struct"
 
-module Standard::Procedure::Async
+module StandardProcedure::Async
   module Actor
     def self.included base
       base.class_eval do
@@ -44,7 +44,7 @@ module Standard::Procedure::Async
     end
 
     def _perform_messages
-      Standard::Procedure::Async.promises.future do
+      StandardProcedure::Async.promises.future do
         while (message = _messages.shift)
           message.call
         end
@@ -52,8 +52,8 @@ module Standard::Procedure::Async
     end
 
     class Message < Concurrent::ImmutableStruct.new(:target, :name, :args, :block, :result)
-      def value
-        result.take
+      def value(timeout: 30)
+        result.take(timeout)
       end
 
       def call

data/lib/{standard/procedure → standard_procedure}/async/error.rb

@@ -1,6 +1,6 @@
 # frozen_string_literal: true
 
-module Standard::Procedure::Async
+module StandardProcedure::Async
   class Error < StandardError
   end
 end

data/lib/{standard/procedure → standard_procedure}/async/promises.rb

@@ -3,7 +3,7 @@
 require_relative "rails_not_loaded_error"
 require "concurrent/promises"
 
-module Standard::Procedure::Async
+module StandardProcedure::Async
   class Promises
     def initialize
       @promises = rails_is_loaded? ? ConcurrentRails::Promises : Concurrent::Promises

data/lib/{standard/procedure → standard_procedure}/async/rails_not_loaded_error.rb

@@ -2,7 +2,7 @@
 
 require_relative "error"
 
-module Standard::Procedure::Async
+module StandardProcedure::Async
   class RailsNotLoadedError < Error
   end
 end

data/lib/standard_procedure/async/version.rb

@@ -0,0 +1,7 @@
+# frozen_string_literal: true
+
+module StandardProcedure
+  module Async
+    VERSION = "0.1.2"
+  end
+end

data/lib/{standard/procedure → standard_procedure}/async.rb

@@ -5,12 +5,10 @@ require_relative "async/error"
 require_relative "async/promises"
 require_relative "async/actor"
 require_relative "async/await"
-module Standard
-  module Procedure
-    module Async
-      def self.promises
-        @promises ||= Promises.new
-      end
+module StandardProcedure
+  module Async
+    def self.promises
+      @promises ||= Promises.new
     end
   end
 end

data/standard-procedure-async.gemspec

@@ -1,10 +1,10 @@
 # frozen_string_literal: true
 
-require_relative "lib/standard/procedure/async/version"
+require_relative "lib/standard_procedure/async/version"
 
 Gem::Specification.new do |spec|
   spec.name = "standard-procedure-async"
-  spec.version = Standard::Procedure::Async::VERSION
+  spec.version = StandardProcedure::Async::VERSION
   spec.authors = ["Rahoul Baruah"]
   spec.email = ["rahoulb@standardprocedure.app"]
 

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: standard-procedure-async
 version: !ruby/object:Gem::Version
-  version: 0.1.0
+  version: 0.1.2
 platform: ruby
 authors:
 - Rahoul Baruah
@@ -82,14 +82,14 @@ files:
 - LICENSE.txt
 - README.md
 - Rakefile
-- lib/standard/procedure/async.rb
-- lib/standard/procedure/async/actor.rb
-- lib/standard/procedure/async/await.rb
-- lib/standard/procedure/async/error.rb
-- lib/standard/procedure/async/promises.rb
-- lib/standard/procedure/async/rails_not_loaded_error.rb
-- lib/standard/procedure/async/version.rb
-- sig/standard/procedure/async.rbs
+- lib/standard_procedure/async.rb
+- lib/standard_procedure/async/actor.rb
+- lib/standard_procedure/async/await.rb
+- lib/standard_procedure/async/error.rb
+- lib/standard_procedure/async/promises.rb
+- lib/standard_procedure/async/rails_not_loaded_error.rb
+- lib/standard_procedure/async/version.rb
+- sig/standard_procedure/async.rbs
 - standard-procedure-async.gemspec
 homepage: https://github.com/standard-procedure/async
 licenses:

data/lib/standard/procedure/async/version.rb

@@ -1,9 +0,0 @@
-# frozen_string_literal: true
-
-module Standard
-  module Procedure
-    module Async
-      VERSION = "0.1.0"
-    end
-  end
-end