tribe 0.2.1 → 0.2.2
Sign up to get free protection for your applications and to get access to all the features.
- data/README.md +35 -17
- data/lib/tribe/version.rb +1 -1
- data/tribe.gemspec +1 -1
- 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
|
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
|
68
|
-
|
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
|
139
|
+
## Futures
|
134
140
|
|
135
|
-
|
136
|
-
|
137
|
-
|
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
|
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
|
210
|
+
Failure to do so will result in many nasty things.
|
198
211
|
|
199
212
|
#### Blocking
|
200
213
|
|
201
|
-
Blocking
|
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
|
-
|
253
|
-
|
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
|
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
data/tribe.gemspec
CHANGED
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.
|
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-
|
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.
|
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.
|
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
|