tribe 0.2.1 → 0.2.2

Sign up to get free protection for your applications and to get access to all the features.
Files changed (4) hide show
  1. data/README.md +35 -17
  2. data/lib/tribe/version.rb +1 -1
  3. data/tribe.gemspec +1 -1
  4. metadata +4 -4
data/README.md CHANGED
@@ -25,6 +25,15 @@ Or install it yourself as:
25
25
 
26
26
  ## Actors
27
27
 
28
+ Actors are light-weight objects which use asynchronous message passing for communcation.
29
+ There are two types of methods that you create in your actors:
30
+
31
+ 1. *Command handlers* are prefixed with "on_" and define the types of commands your actor will process.
32
+ 2. *System handlers* are postfixed with "_handler" and are built into the actor system. These are used for exception, shutdown, and cleanup handling. It is important that you call the super method since their default behavior is used by the actor system.
33
+
34
+ To send a message you use the "enqueue" method and specify a command with an optional data parameter.
35
+ The return value will always be nil since messaging is asynchronous.
36
+
28
37
  # Create your custom actor class.
29
38
  class MyActor < Tribe::Actor
30
39
  private
@@ -52,7 +61,7 @@ Or install it yourself as:
52
61
  MyActor.new(:name => "my_actor_#{i}")
53
62
  end
54
63
 
55
- # Send an event to each actors. Find each actor using the global registry.
64
+ # Send an event to each actor.
56
65
  100.times do |i|
57
66
  actor = Tribe.registry["my_actor_#{i}"]
58
67
  actor.enqueue(:my_custom, 'hello world')
@@ -64,11 +73,11 @@ Or install it yourself as:
64
73
  actor.enqueue(:shutdown)
65
74
  end
66
75
 
67
- #### Implementation notes
68
- *Important*: Because actors use a shared thread pool, it is important that they don't block for long periods of time (short periods are fine).
76
+ #### Implementation
77
+ Because actors use a shared thread pool, it is important that they don't block for long periods of time (short periods are fine).
69
78
  Actors that block for long periods of time should use a dedicated thread (:dedicated => true or subclass from Tribe::DedicatedActor).
70
79
 
71
- #### Options (defaults below):
80
+ #### Options (defaults below)
72
81
 
73
82
  actor = Tribe::Actor.new(
74
83
  :logger => nil, # Ruby logger instance.
@@ -79,9 +88,6 @@ Actors that block for long periods of time should use a dedicated thread (:dedic
79
88
  :name => nil # The name of the actor (must be unique in the registry).
80
89
  )
81
90
 
82
- The DedicatedActor class is a simple wrapper around the Actor class.
83
- It takes all the same options except for :pool and :dedicated since they aren't applicable.
84
-
85
91
  ## Registries
86
92
 
87
93
  Registries hold references to named actors so that you can easily find them.
@@ -130,15 +136,22 @@ Both one-shot and periodic timers are provided.
130
136
  actor.enqueue(:shutdown)
131
137
  end
132
138
 
133
- ## Futures (experimental)
139
+ ## Futures
134
140
 
135
- Futures allow an actor to ask another actor to perform a computation and then return the result.
136
- Tribe includes both blocking and non-blocking actors.
137
- You should prefer to use non-blocking actors in your code when possible due to performance reasons (see details below).
141
+ As mentioned above, message passing with the "enqueue" method is asynchronous and always returns nil.
142
+ This can be a pain since in many cases you will be interested in the result.
143
+
144
+ The "enqueue_future" method helps solve this problem by returning a a Tribe::Future object instead of nil.
145
+ You can then use this object to obtain the result when it becomes available sometime in the future.
146
+
147
+ Tribe includes both blocking and non-blocking futures.
148
+ You should prefer to use non-blocking futures for performance reasons (see details below).
149
+
150
+ In situations where an actor dies, your future will receive the raised exception as the result.
138
151
 
139
152
  #### Non-blocking
140
153
 
141
- Non-blocking actors are asynchronous and use callbacks.
154
+ Non-blocking futures are asynchronous and use callbacks.
142
155
  No waiting for a result is involved.
143
156
  The actor will continue to process other events.
144
157
 
@@ -194,11 +207,11 @@ The actor will continue to process other events.
194
207
 
195
208
  *Important*: You must use Actor#perform inside the above callbacks.
196
209
  This ensures that your code executes within the context of the correct actor.
197
- Failure to do so will result in race conditions and other nasty things.
210
+ Failure to do so will result in many nasty things.
198
211
 
199
212
  #### Blocking
200
213
 
201
- Blocking actors are synchronous.
214
+ Blocking futures are synchronous.
202
215
  The actor won't process any other events until the future has a result.
203
216
 
204
217
  class ActorA < Tribe::Actor
@@ -249,13 +262,16 @@ The actor won't process any other events until the future has a result.
249
262
 
250
263
  #### Futures and Performance
251
264
 
252
- You should prefer non-blocking futures as much as possible in your application code.
253
- This is because a blocking future (Future#wait) causes the current actor (and thread) to sleep.
265
+ Futures have overhead associated with them.
266
+ You should avoid them unless you are actaully interested in the result.
267
+
268
+ You should also prefer non-blocking futures over blocking ones.
269
+ This is because a blocking future causes the current actor (and thread) to sleep.
254
270
 
255
271
  Tribe is designed specifically to support a large number of actors running on a small number of threads.
256
272
  Thus, you will run into performance and/or deadlock problems if too many actors are waiting at the same time.
257
273
 
258
- If you choose to use blocing futures then it is highly recommended that you only use them with dedicated actors.
274
+ If you choose to use blocking futures then it is highly recommended that you only use them with dedicated actors.
259
275
  Each dedicated actor runs in a separate thread (instead of a shared thread pool).
260
276
  The downside to using dedicated actors is that they consume more resources and you can't have as many of them.
261
277
 
@@ -263,6 +279,8 @@ The downside to using dedicated actors is that they consume more resources and y
263
279
 
264
280
  - Supervisors.
265
281
  - Linking.
282
+ - Future timeouts.
283
+ - Clustering.
266
284
 
267
285
  ## Contributing
268
286
 
data/lib/tribe/version.rb CHANGED
@@ -1,3 +1,3 @@
1
1
  module Tribe
2
- VERSION = '0.2.1'
2
+ VERSION = '0.2.2'
3
3
  end
data/tribe.gemspec CHANGED
@@ -15,5 +15,5 @@ Gem::Specification.new do |gem|
15
15
  gem.require_paths = ["lib"]
16
16
  gem.version = Tribe::VERSION
17
17
 
18
- gem.add_dependency('workers', '0.1.2')
18
+ gem.add_dependency('workers', '0.1.4')
19
19
  end
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: tribe
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.2.1
4
+ version: 0.2.2
5
5
  prerelease:
6
6
  platform: ruby
7
7
  authors:
@@ -9,7 +9,7 @@ authors:
9
9
  autorequire:
10
10
  bindir: bin
11
11
  cert_chain: []
12
- date: 2013-05-27 00:00:00.000000000 Z
12
+ date: 2013-06-02 00:00:00.000000000 Z
13
13
  dependencies:
14
14
  - !ruby/object:Gem::Dependency
15
15
  name: workers
@@ -18,7 +18,7 @@ dependencies:
18
18
  requirements:
19
19
  - - '='
20
20
  - !ruby/object:Gem::Version
21
- version: 0.1.2
21
+ version: 0.1.4
22
22
  type: :runtime
23
23
  prerelease: false
24
24
  version_requirements: !ruby/object:Gem::Requirement
@@ -26,7 +26,7 @@ dependencies:
26
26
  requirements:
27
27
  - - '='
28
28
  - !ruby/object:Gem::Version
29
- version: 0.1.2
29
+ version: 0.1.4
30
30
  description: Tribe is a Ruby gem that implements event-driven actors.
31
31
  email:
32
32
  - chad@remesch.com