eventmachine-maglev- 0.12.10 → 1.0.0.beta.4
Sign up to get free protection for your applications and to get access to all the features.
- data/.gitignore +7 -0
- data/.yardopts +7 -0
- data/Gemfile +3 -0
- data/README.md +109 -0
- data/Rakefile +14 -368
- data/docs/DocumentationGuidesIndex.md +27 -0
- data/docs/GettingStarted.md +521 -0
- data/docs/old/DEFERRABLES +246 -0
- data/docs/{KEYBOARD → old/KEYBOARD} +15 -11
- data/docs/old/LIGHTWEIGHT_CONCURRENCY +130 -0
- data/docs/old/SMTP +4 -0
- data/docs/old/SPAWNED_PROCESSES +148 -0
- data/eventmachine.gemspec +20 -26
- data/examples/guides/getting_started/01_eventmachine_echo_server.rb +18 -0
- data/examples/guides/getting_started/02_eventmachine_echo_server_that_recognizes_exit_command.rb +22 -0
- data/examples/guides/getting_started/03_simple_chat_server.rb +149 -0
- data/examples/guides/getting_started/04_simple_chat_server_step_one.rb +27 -0
- data/examples/guides/getting_started/05_simple_chat_server_step_two.rb +43 -0
- data/examples/guides/getting_started/06_simple_chat_server_step_three.rb +98 -0
- data/examples/guides/getting_started/07_simple_chat_server_step_four.rb +121 -0
- data/examples/guides/getting_started/08_simple_chat_server_step_five.rb +141 -0
- data/examples/{ex_channel.rb → old/ex_channel.rb} +3 -3
- data/examples/old/ex_tick_loop_array.rb +15 -0
- data/examples/old/ex_tick_loop_counter.rb +32 -0
- data/ext/binder.cpp +0 -1
- data/ext/cmain.cpp +40 -29
- data/ext/ed.cpp +189 -134
- data/ext/ed.h +34 -40
- data/ext/em.cpp +388 -340
- data/ext/em.h +29 -32
- data/ext/eventmachine.h +7 -6
- data/ext/extconf.rb +57 -48
- data/ext/fastfilereader/extconf.rb +5 -3
- data/ext/fastfilereader/mapper.cpp +1 -1
- data/ext/fastfilereader/rubymain.cpp +0 -1
- data/ext/kb.cpp +1 -3
- data/ext/pipe.cpp +9 -11
- data/ext/project.h +12 -8
- data/ext/rubymain.cpp +158 -112
- data/java/src/com/rubyeventmachine/EmReactor.java +3 -2
- data/lib/em/buftok.rb +35 -63
- data/lib/em/callback.rb +43 -11
- data/lib/em/channel.rb +22 -15
- data/lib/em/completion.rb +303 -0
- data/lib/em/connection.rb +341 -208
- data/lib/em/deferrable/pool.rb +2 -0
- data/lib/em/deferrable.rb +20 -2
- data/lib/em/file_watch.rb +37 -18
- data/lib/em/iterator.rb +270 -0
- data/lib/em/pool.rb +146 -0
- data/lib/em/process_watch.rb +5 -4
- data/lib/em/processes.rb +8 -4
- data/lib/em/protocols/httpclient.rb +27 -11
- data/lib/em/protocols/httpclient2.rb +15 -5
- data/lib/em/protocols/line_protocol.rb +29 -0
- data/lib/em/protocols/memcache.rb +17 -9
- data/lib/em/protocols/object_protocol.rb +2 -1
- data/lib/em/protocols/postgres3.rb +2 -1
- data/lib/em/protocols/smtpclient.rb +19 -11
- data/lib/em/protocols/smtpserver.rb +101 -8
- data/lib/em/protocols/stomp.rb +9 -7
- data/lib/em/protocols/tcptest.rb +3 -2
- data/lib/em/protocols.rb +1 -1
- data/lib/{pr_eventmachine.rb → em/pure_ruby.rb} +188 -205
- data/lib/em/queue.rb +23 -13
- data/lib/em/resolver.rb +192 -0
- data/lib/em/spawnable.rb +9 -10
- data/lib/em/streamer.rb +34 -46
- data/lib/em/threaded_resource.rb +90 -0
- data/lib/em/tick_loop.rb +85 -0
- data/lib/em/timers.rb +8 -3
- data/lib/em/version.rb +1 -1
- data/lib/eventmachine.rb +582 -686
- data/lib/jeventmachine.rb +25 -3
- data/tasks/package.rake +98 -0
- data/tasks/test.rake +8 -0
- data/tests/em_test_helper.rb +64 -0
- data/tests/test_attach.rb +56 -56
- data/tests/test_basic.rb +111 -168
- data/tests/test_channel.rb +5 -6
- data/tests/test_completion.rb +177 -0
- data/tests/test_connection_count.rb +1 -3
- data/tests/test_defer.rb +3 -32
- data/tests/test_deferrable.rb +35 -0
- data/tests/test_epoll.rb +27 -57
- data/tests/test_error_handler.rb +10 -7
- data/tests/test_exc.rb +6 -33
- data/tests/test_file_watch.rb +51 -35
- data/tests/test_futures.rb +10 -38
- data/tests/test_get_sock_opt.rb +27 -20
- data/tests/test_handler_check.rb +1 -3
- data/tests/test_hc.rb +49 -112
- data/tests/test_httpclient.rb +34 -62
- data/tests/test_httpclient2.rb +14 -39
- data/tests/test_inactivity_timeout.rb +44 -40
- data/tests/test_kb.rb +26 -52
- data/tests/test_ltp.rb +27 -71
- data/tests/test_ltp2.rb +1 -30
- data/tests/test_next_tick.rb +2 -31
- data/tests/test_object_protocol.rb +8 -9
- data/tests/test_pause.rb +45 -37
- data/tests/test_pending_connect_timeout.rb +42 -38
- data/tests/test_pool.rb +128 -0
- data/tests/test_process_watch.rb +37 -37
- data/tests/test_processes.rb +92 -110
- data/tests/test_proxy_connection.rb +137 -61
- data/tests/test_pure.rb +30 -67
- data/tests/test_queue.rb +10 -4
- data/tests/test_resolver.rb +55 -0
- data/tests/test_running.rb +1 -29
- data/tests/test_sasl.rb +8 -33
- data/tests/test_send_file.rb +163 -188
- data/tests/test_servers.rb +12 -55
- data/tests/test_shutdown_hooks.rb +23 -0
- data/tests/test_smtpclient.rb +1 -29
- data/tests/test_smtpserver.rb +1 -29
- data/tests/test_spawn.rb +2 -31
- data/tests/test_ssl_args.rb +9 -10
- data/tests/test_ssl_methods.rb +1 -3
- data/tests/test_ssl_verify.rb +63 -63
- data/tests/test_threaded_resource.rb +53 -0
- data/tests/test_tick_loop.rb +59 -0
- data/tests/test_timers.rb +52 -91
- data/tests/test_ud.rb +1 -29
- data/tests/test_unbind_reason.rb +31 -0
- metadata +113 -70
- data/README +0 -82
- data/docs/DEFERRABLES +0 -133
- data/docs/LIGHTWEIGHT_CONCURRENCY +0 -70
- data/docs/SMTP +0 -2
- data/docs/SPAWNED_PROCESSES +0 -89
- data/ext/cplusplus.cpp +0 -202
- data/ext/emwin.cpp +0 -300
- data/ext/emwin.h +0 -94
- data/ext/epoll.cpp +0 -26
- data/ext/epoll.h +0 -25
- data/ext/eventmachine_cpp.h +0 -96
- data/ext/files.cpp +0 -94
- data/ext/files.h +0 -65
- data/ext/sigs.cpp +0 -89
- data/ext/sigs.h +0 -32
- data/java/src/com/rubyeventmachine/application/Application.java +0 -194
- data/java/src/com/rubyeventmachine/application/Connection.java +0 -74
- data/java/src/com/rubyeventmachine/application/ConnectionFactory.java +0 -37
- data/java/src/com/rubyeventmachine/application/DefaultConnectionFactory.java +0 -46
- data/java/src/com/rubyeventmachine/application/PeriodicTimer.java +0 -38
- data/java/src/com/rubyeventmachine/application/Timer.java +0 -54
- data/java/src/com/rubyeventmachine/tests/ApplicationTest.java +0 -109
- data/java/src/com/rubyeventmachine/tests/ConnectTest.java +0 -148
- data/java/src/com/rubyeventmachine/tests/EMTest.java +0 -80
- data/java/src/com/rubyeventmachine/tests/TestDatagrams.java +0 -53
- data/java/src/com/rubyeventmachine/tests/TestServers.java +0 -75
- data/java/src/com/rubyeventmachine/tests/TestTimers.java +0 -90
- data/lib/evma/callback.rb +0 -32
- data/lib/evma/container.rb +0 -75
- data/lib/evma/factory.rb +0 -77
- data/lib/evma/protocol.rb +0 -87
- data/lib/evma/reactor.rb +0 -48
- data/lib/evma.rb +0 -32
- data/setup.rb +0 -1585
- data/tests/test_errors.rb +0 -82
- data/tests/testem.rb +0 -31
- data/web/whatis +0 -7
- /data/{docs/GNU → GNU} +0 -0
- /data/{docs/COPYING → LICENSE} +0 -0
- /data/docs/{ChangeLog → old/ChangeLog} +0 -0
- /data/docs/{EPOLL → old/EPOLL} +0 -0
- /data/docs/{INSTALL → old/INSTALL} +0 -0
- /data/docs/{LEGAL → old/LEGAL} +0 -0
- /data/docs/{PURE_RUBY → old/PURE_RUBY} +0 -0
- /data/docs/{RELEASE_NOTES → old/RELEASE_NOTES} +0 -0
- /data/docs/{TODO → old/TODO} +0 -0
- /data/examples/{ex_queue.rb → old/ex_queue.rb} +0 -0
- /data/examples/{helper.rb → old/helper.rb} +0 -0
@@ -0,0 +1,246 @@
|
|
1
|
+
EventMachine (EM) adds two different formalisms for lightweight concurrency
|
2
|
+
to the Ruby programmer's toolbox: spawned processes and deferrables. This
|
3
|
+
note will show you how to use deferrables. For more information, see the
|
4
|
+
separate document LIGHTWEIGHT_CONCURRENCY.
|
5
|
+
|
6
|
+
=== What are Deferrables?
|
7
|
+
|
8
|
+
EventMachine's Deferrable borrows heavily from the "deferred" object in
|
9
|
+
Python's "Twisted" event-handling framework. Here's a minimal example that
|
10
|
+
illustrates Deferrable:
|
11
|
+
|
12
|
+
require 'eventmachine'
|
13
|
+
|
14
|
+
class MyClass
|
15
|
+
include EM::Deferrable
|
16
|
+
|
17
|
+
def print_value x
|
18
|
+
puts "MyClass instance received #{x}"
|
19
|
+
end
|
20
|
+
end
|
21
|
+
|
22
|
+
EM.run {
|
23
|
+
df = MyClass.new
|
24
|
+
df.callback {|x|
|
25
|
+
df.print_value(x)
|
26
|
+
EM.stop
|
27
|
+
}
|
28
|
+
|
29
|
+
EM::Timer.new(2) {
|
30
|
+
df.set_deferred_status :succeeded, 100
|
31
|
+
}
|
32
|
+
}
|
33
|
+
|
34
|
+
|
35
|
+
This program will spin for two seconds, print out the string "MyClass
|
36
|
+
instance received 100" and then exit. The Deferrable pattern relies on
|
37
|
+
an unusual metaphor that may be unfamiliar to you, unless you've used
|
38
|
+
Python's Twisted. You may need to read the following material through
|
39
|
+
more than once before you get the idea.
|
40
|
+
|
41
|
+
EventMachine::Deferrable is simply a Ruby Module that you can include
|
42
|
+
in your own classes. (There also is a class named
|
43
|
+
EventMachine::DefaultDeferrable for when you want to create one without
|
44
|
+
including it in code of your own.)
|
45
|
+
|
46
|
+
An object that includes EventMachine::Deferrable is like any other Ruby
|
47
|
+
object: it can be created whenever you want, returned from your functions,
|
48
|
+
or passed as an argument to other functions.
|
49
|
+
|
50
|
+
The Deferrable pattern allows you to specify any number of Ruby code
|
51
|
+
blocks (callbacks or errbacks) that will be executed at some future time
|
52
|
+
when the status of the Deferrable object changes.
|
53
|
+
|
54
|
+
How might that be useful? Well, imagine that you're implementing an HTTP
|
55
|
+
server, but you need to make a call to some other server in order to fulfill
|
56
|
+
a client request.
|
57
|
+
|
58
|
+
When you receive a request from one of your clients, you can create and
|
59
|
+
return a Deferrable object. Some other section of your program can add a
|
60
|
+
callback to the Deferrable that will cause the client's request to be
|
61
|
+
fulfilled. Simultaneously, you initiate an event-driven or threaded client
|
62
|
+
request to some different server. And then your EM program will continue to
|
63
|
+
process other events and service other client requests.
|
64
|
+
|
65
|
+
When your client request to the other server completes some time later, you
|
66
|
+
will call the #set_deferred_status method on the Deferrable object, passing
|
67
|
+
either a success or failure status, and an arbitrary number of parameters
|
68
|
+
(which might include the data you received from the other server).
|
69
|
+
|
70
|
+
At that point, the status of the Deferrable object becomes known, and its
|
71
|
+
callback or errback methods are immediately executed. Callbacks and errbacks
|
72
|
+
are code blocks that are attached to Deferrable objects at any time through
|
73
|
+
the methods #callback and #errback.
|
74
|
+
|
75
|
+
The deep beauty of this pattern is that it decouples the disposition of one
|
76
|
+
operation (such as a client request to an outboard server) from the
|
77
|
+
subsequent operations that depend on that disposition (which may include
|
78
|
+
responding to a different client or any other operation).
|
79
|
+
|
80
|
+
The code which invokes the deferred operation (that will eventually result
|
81
|
+
in a success or failure status together with associated data) is completely
|
82
|
+
separate from the code which depends on that status and data. This achieves
|
83
|
+
one of the primary goals for which threading is typically used in
|
84
|
+
sophisticated applications, with none of the nondeterminacy or debugging
|
85
|
+
difficulties of threads.
|
86
|
+
|
87
|
+
As soon as the deferred status of a Deferrable becomes known by way of a call
|
88
|
+
to #set_deferred_status, the Deferrable will IMMEDIATELY execute all of its
|
89
|
+
callbacks or errbacks in the order in which they were added to the Deferrable.
|
90
|
+
|
91
|
+
Callbacks and errbacks can be added to a Deferrable object at any time, not
|
92
|
+
just when the object is created. They can even be added after the status of
|
93
|
+
the object has been determined! (In this case, they will be executed
|
94
|
+
immediately when they are added.)
|
95
|
+
|
96
|
+
A call to Deferrable#set_deferred_status takes :succeeded or :failed as its
|
97
|
+
first argument. (This determines whether the object will call its callbacks
|
98
|
+
or its errbacks.) #set_deferred_status also takes zero or more additional
|
99
|
+
parameters, that will in turn be passed as parameters to the callbacks or
|
100
|
+
errbacks.
|
101
|
+
|
102
|
+
In general, you can only call #set_deferred_status ONCE on a Deferrable
|
103
|
+
object. A call to #set_deferred_status will not return until all of the
|
104
|
+
associated callbacks or errbacks have been called. If you add callbacks or
|
105
|
+
errbacks AFTER making a call to #set_deferred_status, those additional
|
106
|
+
callbacks or errbacks will execute IMMEDIATELY. Any given callback or
|
107
|
+
errback will be executed AT MOST once.
|
108
|
+
|
109
|
+
It's possible to call #set_deferred_status AGAIN, during the execution a
|
110
|
+
callback or errback. This makes it possible to change the parameters which
|
111
|
+
will be sent to the callbacks or errbacks farther down the chain, enabling
|
112
|
+
some extremely elegant use-cases. You can transform the data returned from
|
113
|
+
a deferred operation in arbitrary ways as needed by subsequent users, without
|
114
|
+
changing any of the code that generated the original data.
|
115
|
+
|
116
|
+
A call to #set_deferred_status will not return until all of the associated
|
117
|
+
callbacks or errbacks have been called. If you add callbacks or errbacks
|
118
|
+
AFTER making a call to #set_deferred_status, those additional callbacks or
|
119
|
+
errbacks will execute IMMEDIATELY.
|
120
|
+
|
121
|
+
Let's look at some more sample code. It turns out that many of the internal
|
122
|
+
protocol implementations in the EventMachine package rely on Deferrable. One
|
123
|
+
of these is EM::Protocols::HttpClient.
|
124
|
+
|
125
|
+
To make an evented HTTP request, use the module function
|
126
|
+
EM::Protocols::HttpClient#request, which returns a Deferrable object.
|
127
|
+
Here's how:
|
128
|
+
|
129
|
+
require 'eventmachine'
|
130
|
+
|
131
|
+
EM.run {
|
132
|
+
df = EM::Protocols::HttpClient.request( :host=>"www.example.com",
|
133
|
+
:request=>"/index.html" )
|
134
|
+
|
135
|
+
df.callback {|response|
|
136
|
+
puts "Succeeded: #{response[:content]}"
|
137
|
+
EM.stop
|
138
|
+
}
|
139
|
+
|
140
|
+
df.errback {|response|
|
141
|
+
puts "ERROR: #{response[:status]}"
|
142
|
+
EM.stop
|
143
|
+
}
|
144
|
+
}
|
145
|
+
|
146
|
+
(See the documentation of EventMachine::Protocols::HttpClient for information
|
147
|
+
on the object returned by #request.)
|
148
|
+
|
149
|
+
In this code, we make a call to HttpClient#request, which immediately returns
|
150
|
+
a Deferrable object. In the background, an HTTP client request is being made
|
151
|
+
to www.example.com, although your code will continue to run concurrently.
|
152
|
+
|
153
|
+
At some future point, the HTTP client request will complete, and the code in
|
154
|
+
EM::Protocols::HttpClient will process either a valid HTTP response (including
|
155
|
+
returned content), or an error.
|
156
|
+
|
157
|
+
At that point, EM::Protocols::HttpClient will call
|
158
|
+
EM::Deferrable#set_deferred_status on the Deferrable object that was returned
|
159
|
+
to your program, as the return value from EM::Protocols::HttpClient.request.
|
160
|
+
You don't have to do anything to make this happen. All you have to do is tell
|
161
|
+
the Deferrable what to do in case of either success, failure, or both.
|
162
|
+
|
163
|
+
In our code sample, we set one callback and one errback. The former will be
|
164
|
+
called if the HTTP call succeeds, and the latter if it fails. (For
|
165
|
+
simplicity, we have both of them calling EM#stop to end the program, although
|
166
|
+
real programs would be very unlikely to do this.)
|
167
|
+
|
168
|
+
Setting callbacks and errbacks is optional. They are handlers to defined
|
169
|
+
events in the lifecycle of the Deferrable event. It's not an error if you
|
170
|
+
fail to set either a callback, an errback, or both. But of course your
|
171
|
+
program will then fail to receive those notifications.
|
172
|
+
|
173
|
+
If through some bug it turns out that #set_deferred_status is never called
|
174
|
+
on a Deferrable object, then that object's callbacks or errbacks will NEVER
|
175
|
+
be called. It's also possible to set a timeout on a Deferrable. If the
|
176
|
+
timeout elapses before any other call to #set_deferred_status, the Deferrable
|
177
|
+
object will behave as is you had called set_deferred_status(:failed) on it.
|
178
|
+
|
179
|
+
|
180
|
+
Now let's modify the example to illustrate some additional points:
|
181
|
+
|
182
|
+
require 'eventmachine'
|
183
|
+
|
184
|
+
EM.run {
|
185
|
+
df = EM::Protocols::HttpClient.request( :host=>"www.example.com",
|
186
|
+
:request=>"/index.html" )
|
187
|
+
|
188
|
+
df.callback {|response|
|
189
|
+
df.set_deferred_status :succeeded, response[:content]
|
190
|
+
}
|
191
|
+
|
192
|
+
df.callback {|string|
|
193
|
+
puts "Succeeded: #{string}"
|
194
|
+
EM.stop
|
195
|
+
}
|
196
|
+
|
197
|
+
df.errback {|response|
|
198
|
+
puts "ERROR: #{response[:status]}"
|
199
|
+
EM.stop
|
200
|
+
}
|
201
|
+
}
|
202
|
+
|
203
|
+
|
204
|
+
Just for the sake of illustration, we've now set two callbacks instead of
|
205
|
+
one. If the deferrable operation (the HTTP client-request) succeeds, then
|
206
|
+
both of the callbacks will be executed in order.
|
207
|
+
|
208
|
+
But notice that we've also made our own call to #set_deferred_status in the
|
209
|
+
first callback. This isn't required, because the HttpClient implementation
|
210
|
+
already made a call to #set_deferred_status. (Otherwise, of course, the
|
211
|
+
callback would not be executing.)
|
212
|
+
|
213
|
+
But we used #set_deferred_status in the first callback in order to change the
|
214
|
+
parameters that will be sent to subsequent callbacks in the chain. In this
|
215
|
+
way, you can construct powerful sequences of layered functionality. If you
|
216
|
+
want, you can even change the status of the Deferrable from :succeeded to
|
217
|
+
:failed, which would abort the chain of callback calls, and invoke the chain
|
218
|
+
of errbacks instead.
|
219
|
+
|
220
|
+
Now of course it's somewhat trivial to define two callbacks in the same
|
221
|
+
method, even with the parameter-changing effect we just described. It would
|
222
|
+
be much more interesting to pass the Deferrable to some other function (for
|
223
|
+
example, a function defined in another module or a different gem), that would
|
224
|
+
in turn add callbacks and/or errbacks of its own. That would illustrate the
|
225
|
+
true power of the Deferrable pattern: to isolate the HTTP client-request
|
226
|
+
from other functions that use the data that it returns without caring where
|
227
|
+
those data came from.
|
228
|
+
|
229
|
+
Remember that you can add a callback or an errback to a Deferrable at any
|
230
|
+
point in time, regardless of whether the status of the deferred operation is
|
231
|
+
known (more precisely, regardless of when #set_deferred_status is called on
|
232
|
+
the object). Even hours or days later.
|
233
|
+
|
234
|
+
When you add a callback or errback to a Deferrable object on which
|
235
|
+
#set_deferred_status has not yet been called, the callback/errback is queued
|
236
|
+
up for future execution, inside the Deferrable object. When you add a
|
237
|
+
callback or errback to a Deferrable on which #set_deferred_status has
|
238
|
+
already been called, the callback/errback will be executed immediately.
|
239
|
+
Your code doesn't have to worry about the ordering, and there are no timing
|
240
|
+
issues, as there would be with a threaded approach.
|
241
|
+
|
242
|
+
For more information on Deferrables and their typical usage patterns, look
|
243
|
+
in the EM unit tests. There are also quite a few sugarings (including
|
244
|
+
EM::Deferrable#future) that make typical Deferrable usages syntactically
|
245
|
+
easier to work with.
|
246
|
+
|
@@ -1,38 +1,42 @@
|
|
1
|
-
EventMachine (EM) can respond to keyboard events. This gives your event-driven
|
1
|
+
EventMachine (EM) can respond to keyboard events. This gives your event-driven
|
2
|
+
programs the ability to respond to input from local users.
|
2
3
|
|
3
|
-
Programming EM to handle keyboard input in Ruby is simplicity itself. Just use
|
4
|
+
Programming EM to handle keyboard input in Ruby is simplicity itself. Just use
|
5
|
+
EventMachine#open_keyboard, and supply the name of a Ruby module or class that
|
6
|
+
will receive the input:
|
4
7
|
|
5
8
|
require 'rubygems'
|
6
9
|
require 'eventmachine'
|
7
|
-
|
10
|
+
|
8
11
|
module MyKeyboardHandler
|
9
12
|
def receive_data keystrokes
|
10
13
|
puts "I received the following data from the keyboard: #{keystrokes}"
|
11
14
|
end
|
12
15
|
end
|
13
|
-
|
16
|
+
|
14
17
|
EM.run {
|
15
18
|
EM.open_keyboard(MyKeyboardHandler)
|
16
19
|
}
|
17
20
|
|
18
|
-
|
19
|
-
|
20
|
-
|
21
|
-
|
21
|
+
If you want EM to send line-buffered keyboard input to your program, just
|
22
|
+
include the LineText2 protocol module in your handler class or module:
|
22
23
|
|
23
24
|
require 'rubygems'
|
24
25
|
require 'eventmachine'
|
25
|
-
|
26
|
+
|
26
27
|
module MyKeyboardHandler
|
27
28
|
include EM::Protocols::LineText2
|
28
29
|
def receive_line data
|
29
30
|
puts "I received the following line from the keyboard: #{data}"
|
30
31
|
end
|
31
32
|
end
|
32
|
-
|
33
|
+
|
33
34
|
EM.run {
|
34
35
|
EM.open_keyboard(MyKeyboardHandler)
|
35
36
|
}
|
36
37
|
|
37
|
-
As we said, simplicity itself. You can call EventMachine#open_keyboard at any
|
38
|
+
As we said, simplicity itself. You can call EventMachine#open_keyboard at any
|
39
|
+
time while the EM reactor loop is running. In other words, the method
|
40
|
+
invocation may appear anywhere in an EventMachine#run block, or in any code
|
41
|
+
invoked in the #run block.
|
38
42
|
|
@@ -0,0 +1,130 @@
|
|
1
|
+
EventMachine (EM) adds two different formalisms for lightweight concurrency to
|
2
|
+
the Ruby programmer's toolbox: spawned processes and deferrables. This note
|
3
|
+
will show you how to use them.
|
4
|
+
|
5
|
+
|
6
|
+
=== What is Lightweight Concurrency?
|
7
|
+
|
8
|
+
We use the term "Lightweight Concurrency" (LC) to refer to concurrency
|
9
|
+
mechanisms that are lighter than Ruby threads. By "lighter," we mean: less
|
10
|
+
resource-intensive in one or more dimensions, usually including memory and
|
11
|
+
CPU usage. In general, you turn to LC in the hope of improving the
|
12
|
+
performance and scalability of your programs.
|
13
|
+
|
14
|
+
In addition to the two EventMachine mechanisms we will discuss here, Ruby
|
15
|
+
has at least one other LC construct: Fibers, which are currently under
|
16
|
+
development in Ruby 1.9.
|
17
|
+
|
18
|
+
The technical feature that makes all of these LC mechanisms different from
|
19
|
+
standard Ruby threads is that they are not scheduled automatically.
|
20
|
+
|
21
|
+
When you create and run Ruby threads, you can assume (within certain
|
22
|
+
constraints) that your threads will all be scheduled fairly by Ruby's runtime.
|
23
|
+
Ruby itself is responsible for giving each of your threads its own share of
|
24
|
+
the total runtime.
|
25
|
+
|
26
|
+
But with LC, your program is responsible for causing different execution
|
27
|
+
paths to run. In effect, your program has to act as a "thread scheduler."
|
28
|
+
Scheduled entities in LC run to completion and are never preempted. The
|
29
|
+
runtime system has far less work to do since it has no need to interrupt
|
30
|
+
threads or to schedule them fairly. This is what makes LC lighter and faster.
|
31
|
+
|
32
|
+
You'll learn exactly how LC scheduling works in practice as we work through
|
33
|
+
specific examples.
|
34
|
+
|
35
|
+
|
36
|
+
=== EventMachine Lightweight Concurrency
|
37
|
+
|
38
|
+
Recall that EM provides a reactor loop that must be running in order for
|
39
|
+
your programs to perform event-driven logic. An EM program typically has a
|
40
|
+
structure like this:
|
41
|
+
|
42
|
+
require 'eventmachine'
|
43
|
+
|
44
|
+
# your initializations
|
45
|
+
|
46
|
+
EM.run {
|
47
|
+
# perform event-driven I/O here, including network clients,
|
48
|
+
# servers, timers, and thread-pool operations.
|
49
|
+
}
|
50
|
+
|
51
|
+
# your cleanup
|
52
|
+
# end of the program
|
53
|
+
|
54
|
+
|
55
|
+
EventMachine#run executes the reactor loop, which causes your code to be
|
56
|
+
called as events of interest to your program occur. The block you pass to
|
57
|
+
EventMachine#run is executed right after the reactor loop starts, and is
|
58
|
+
the right place to start socket acceptors, etc.
|
59
|
+
|
60
|
+
Because the reactor loop runs constantly in an EM program (until it is
|
61
|
+
stopped by a call to EventMachine#stop), it has the ability to schedule
|
62
|
+
blocks of code for asynchronous execution. Unlike a pre-emptive thread
|
63
|
+
scheduler, it's NOT able to interrupt code blocks while they execute. But
|
64
|
+
the scheduling capability it does have is enough to enable lightweight
|
65
|
+
concurrency.
|
66
|
+
|
67
|
+
|
68
|
+
For information on Spawned Processes, see the separate document
|
69
|
+
SPAWNED_PROCESSES.
|
70
|
+
|
71
|
+
For information on Deferrables, see the separate document DEFERRABLES.
|
72
|
+
|
73
|
+
|
74
|
+
=== [SIDEBAR]: I Heard That EventMachine Doesn't Work With Ruby Threads.
|
75
|
+
|
76
|
+
This is incorrect. EM is fully interoperable with all versions of Ruby
|
77
|
+
threads, and has been since its earliest releases.
|
78
|
+
|
79
|
+
It's very true that EM encourages an "evented" (non-threaded) programming
|
80
|
+
style. The specific benefits of event-driven programming are far better
|
81
|
+
performance and scalability for well-written programs, and far easier
|
82
|
+
debugging.
|
83
|
+
|
84
|
+
The benefit of using threads for similar applications is a possibly more
|
85
|
+
intuitive programming model, as well as the fact that threads are already
|
86
|
+
familiar to most programmers. Also, bugs in threaded programs often fail
|
87
|
+
to show up until programs go into production. These factors create the
|
88
|
+
illusion that threaded programs are easier to write.
|
89
|
+
|
90
|
+
However, some operations that occur frequently in professional-caliber
|
91
|
+
applications simply can't be done without threads. (The classic example
|
92
|
+
is making calls to database client-libraries that block on network I/O
|
93
|
+
until they complete.)
|
94
|
+
|
95
|
+
EventMachine not only allows the use of Ruby threads in these cases, but
|
96
|
+
it even provides a built-in thread-pool object to make them easier to
|
97
|
+
work with.
|
98
|
+
|
99
|
+
You may have heard a persistent criticism that evented I/O is fundamentally
|
100
|
+
incompatible with Ruby threads. It is true that some well-publicized attempts
|
101
|
+
to incorporate event-handling libraries into Ruby were not successful. But
|
102
|
+
EventMachine was designed from the ground up with Ruby compatibility in mind,
|
103
|
+
so EM never suffered from the problems that defeated the earlier attempts.
|
104
|
+
|
105
|
+
|
106
|
+
=== [SIDEBAR]: I Heard That EventMachine Doesn't Work Very Well On Windows.
|
107
|
+
|
108
|
+
This too is incorrect. EventMachine is an extension written in C++ and Java,
|
109
|
+
and therefore it requires compilation. Many Windows computers (and some Unix
|
110
|
+
computers, especially in production environments) don't have a build stack.
|
111
|
+
Attempting to install EventMachine on a machine without a compiler usually
|
112
|
+
produces a confusing error.
|
113
|
+
|
114
|
+
In addition, Ruby has a much-debated issue with Windows compiler versions.
|
115
|
+
Ruby on Windows works best with Visual Studio 6, a compiler version that is
|
116
|
+
long out-of-print, no longer supported by Microsoft, and difficult to obtain.
|
117
|
+
(This problem is not specific to EventMachine.)
|
118
|
+
|
119
|
+
Shortly after EventMachine was first released, the compiler issues led to
|
120
|
+
criticism that EM was incompatible with Windows. Since that time, every
|
121
|
+
EventMachine release has been supplied in a precompiled binary form for
|
122
|
+
Windows users, that does not require you to compile the code yourself. EM
|
123
|
+
binary Gems for Windows are compiled using Visual Studio 6.
|
124
|
+
|
125
|
+
EventMachine does supply some advanced features (such as Linux EPOLL support,
|
126
|
+
reduced-privilege operation, UNIX-domain sockets, etc.) that have no
|
127
|
+
meaningful implementation on Windows. Apart from these special cases, all EM
|
128
|
+
functionality (including lightweight concurrency) works perfectly well on
|
129
|
+
Windows.
|
130
|
+
|
data/docs/old/SMTP
ADDED
@@ -0,0 +1,148 @@
|
|
1
|
+
EventMachine (EM) adds two different formalisms for lightweight concurrency
|
2
|
+
to the Ruby programmer's toolbox: spawned processes and deferrables. This
|
3
|
+
note will show you how to use spawned processes. For more information, see
|
4
|
+
the separate document LIGHTWEIGHT_CONCURRENCY.
|
5
|
+
|
6
|
+
|
7
|
+
=== What are Spawned Processes?
|
8
|
+
|
9
|
+
Spawned Processes in EventMachine are inspired directly by the "processes"
|
10
|
+
found in the Erlang programming language. EM deliberately borrows much (but
|
11
|
+
not all) of Erlang's terminology. However, EM's spawned processes differ from
|
12
|
+
Erlang's in ways that reflect not only Ruby style, but also the fact that
|
13
|
+
Ruby is not a functional language like Erlang.
|
14
|
+
|
15
|
+
Let's proceed with a complete, working code sample that we will analyze line
|
16
|
+
by line. Here's an EM implementation of the "ping-pong" program that also
|
17
|
+
appears in the Erlang tutorial:
|
18
|
+
|
19
|
+
|
20
|
+
require 'eventmachine'
|
21
|
+
|
22
|
+
EM.run {
|
23
|
+
pong = EM.spawn {|x, ping|
|
24
|
+
puts "Pong received #{x}"
|
25
|
+
ping.notify( x-1 )
|
26
|
+
}
|
27
|
+
|
28
|
+
ping = EM.spawn {|x|
|
29
|
+
if x > 0
|
30
|
+
puts "Pinging #{x}"
|
31
|
+
pong.notify x, self
|
32
|
+
else
|
33
|
+
EM.stop
|
34
|
+
end
|
35
|
+
}
|
36
|
+
|
37
|
+
ping.notify 3
|
38
|
+
}
|
39
|
+
|
40
|
+
If you run this program, you'll see the following output:
|
41
|
+
|
42
|
+
Pinging 3
|
43
|
+
Pong received 3
|
44
|
+
Pinging 2
|
45
|
+
Pong received 2
|
46
|
+
Pinging 1
|
47
|
+
Pong received 1
|
48
|
+
|
49
|
+
Let's take it step by step.
|
50
|
+
|
51
|
+
EventMachine#spawn works very much like the built-in function spawn in
|
52
|
+
Erlang. It returns a reference to a Ruby object of class
|
53
|
+
EventMachine::SpawnedProcess, which is actually a schedulable entity. In
|
54
|
+
Erlang, the value returned from spawn is called a "process identifier" or
|
55
|
+
"pid." But we'll refer to the Ruby object returned from EM#spawn simply as a
|
56
|
+
"spawned process."
|
57
|
+
|
58
|
+
You pass a Ruby block with zero or more parameters to EventMachine#spawn.
|
59
|
+
Like all Ruby blocks, this one is a closure, so it can refer to variables
|
60
|
+
defined in the local context when you call EM#spawn.
|
61
|
+
|
62
|
+
However, the code block passed to EM#spawn does NOT execute immediately by
|
63
|
+
default. Rather, it will execute only when the Spawned Object is "notified."
|
64
|
+
In Erlang, this process is called "message passing," and is done with the
|
65
|
+
operator !, but in Ruby it's done simply by calling the #notify method of a
|
66
|
+
spawned-process object. The parameters you pass to #notify must match those
|
67
|
+
defined in the block that was originally passed to EM#spawn.
|
68
|
+
|
69
|
+
When you call the #notify method of a spawned-process object, EM's reactor
|
70
|
+
core will execute the code block originally passed to EM#spawn, at some point
|
71
|
+
in the future. (#notify itself merely adds a notification to the object's
|
72
|
+
message queue and ALWAYS returns immediately.)
|
73
|
+
|
74
|
+
When a SpawnedProcess object executes a notification, it does so in the
|
75
|
+
context of the SpawnedProcess object itself. The notified code block can see
|
76
|
+
local context from the point at which EM#spawn was called. However, the value
|
77
|
+
of "self" inside the notified code block is a reference to the SpawnedProcesss
|
78
|
+
object itself.
|
79
|
+
|
80
|
+
An EM spawned process is nothing more than a Ruby object with a message
|
81
|
+
queue attached to it. You can have any number of spawned processes in your
|
82
|
+
program without compromising scalability. You can notify a spawned process
|
83
|
+
any number of times, and each notification will cause a "message" to be
|
84
|
+
placed in the queue of the spawned process. Spawned processes with non-empty
|
85
|
+
message queues are scheduled for execution automatically by the EM reactor.
|
86
|
+
Spawned processes with no visible references are garbage-collected like any
|
87
|
+
other Ruby object.
|
88
|
+
|
89
|
+
Back to our code sample:
|
90
|
+
|
91
|
+
pong = EM.spawn {|x, ping|
|
92
|
+
puts "Pong received #{x}"
|
93
|
+
ping.notify( x-1 )
|
94
|
+
}
|
95
|
+
|
96
|
+
This simply creates a spawned process and assigns it to the local variable
|
97
|
+
pong. You can see that the spawned code block takes a numeric parameter and a
|
98
|
+
reference to another spawned process. When pong is notified, it expects to
|
99
|
+
receive arguments corresponding to these two parameters. It simply prints out
|
100
|
+
the number it receives as the first argument. Then it notifies the spawned
|
101
|
+
process referenced by the second argument, passing it the first argument
|
102
|
+
minus 1.
|
103
|
+
|
104
|
+
And then the block ends, which is crucial because otherwise nothing else
|
105
|
+
can run. (Remember that in LC, scheduled entities run to completion and are
|
106
|
+
never preempted.)
|
107
|
+
|
108
|
+
On to the next bit of the code sample:
|
109
|
+
|
110
|
+
ping = EM.spawn {|x|
|
111
|
+
if x > 0
|
112
|
+
puts "Pinging #{x}"
|
113
|
+
pong.notify x, self
|
114
|
+
else
|
115
|
+
EM.stop
|
116
|
+
end
|
117
|
+
}
|
118
|
+
|
119
|
+
Here, we're spawning a process that takes a single (numeric) parameter. If
|
120
|
+
the parameter is greater than zero, the block writes it to the console. It
|
121
|
+
then notifies the spawned process referenced by the pong local variable,
|
122
|
+
passing as arguments its number argument, and a reference to itself. The
|
123
|
+
latter reference, as you saw above, is used by pong to send a return
|
124
|
+
notification.
|
125
|
+
|
126
|
+
If the ping process receives a zero value, it will stop the reactor loop and
|
127
|
+
end the program.
|
128
|
+
|
129
|
+
Now we've created a pair of spawned processes, but nothing else has happened.
|
130
|
+
If we stop now, the program will spin in the EM reactor loop, doing nothing
|
131
|
+
at all. Our spawned processes will never be scheduled for execution.
|
132
|
+
|
133
|
+
But look at the next line in the code sample:
|
134
|
+
|
135
|
+
ping.notify 3
|
136
|
+
|
137
|
+
This line gets the ping-pong ball rolling. We call ping's #notify method,
|
138
|
+
passing the argument 3. This causes a message to be sent to the ping spawned
|
139
|
+
process. The message contains the single argument, and it causes the EM
|
140
|
+
reactor to schedule the ping process. And this in turn results in the
|
141
|
+
execution of the Ruby code block passed to EM#spawn when ping was created.
|
142
|
+
Everything else proceeds as a result of the messages that are subsequently
|
143
|
+
passed to each other by the spawned processes.
|
144
|
+
|
145
|
+
[TODO, present the outbound network i/o use case, and clarify that spawned
|
146
|
+
processes are interleaved with normal i/o operations and don't interfere
|
147
|
+
with them at all. Also, blame Erlang for the confusing term "process"]
|
148
|
+
|
data/eventmachine.gemspec
CHANGED
@@ -1,13 +1,24 @@
|
|
1
1
|
# -*- encoding: utf-8 -*-
|
2
|
+
require File.expand_path('../lib/em/version', __FILE__) unless defined? EventMachine
|
2
3
|
|
3
4
|
Gem::Specification.new do |s|
|
4
|
-
s.name =
|
5
|
-
s.version =
|
5
|
+
s.name = 'eventmachine-maglev-'
|
6
|
+
s.version = EventMachine::VERSION
|
7
|
+
s.homepage = 'http://rubyeventmachine.com'
|
8
|
+
s.rubyforge_project = 'eventmachine'
|
6
9
|
|
7
|
-
s.
|
8
|
-
s.
|
9
|
-
|
10
|
-
s.
|
10
|
+
s.authors = ["Francis Cianfrocca", "Aman Gupta"]
|
11
|
+
s.email = ["garbagecat10@gmail.com", "aman@tmm1.net"]
|
12
|
+
|
13
|
+
s.files = `git ls-files`.split("\n")
|
14
|
+
s.extensions = ["ext/extconf.rb", "ext/fastfilereader/extconf.rb"]
|
15
|
+
|
16
|
+
s.add_development_dependency 'rake-compiler', '0.7.6'
|
17
|
+
s.add_development_dependency 'yard', ">= 0.7.2"
|
18
|
+
s.add_development_dependency 'bluecloth'
|
19
|
+
|
20
|
+
s.summary = 'Ruby/EventMachine library'
|
21
|
+
s.description = "EventMachine implements a fast, single-threaded engine for arbitrary network
|
11
22
|
communications. It's extremely easy to use in Ruby. EventMachine wraps all
|
12
23
|
interactions with IP sockets, allowing programs to concentrate on the
|
13
24
|
implementation of network protocols. It can be used to create both network
|
@@ -16,25 +27,8 @@ to specify the IP address and port, and provide a Module that implements the
|
|
16
27
|
communications protocol. Implementations of several standard network protocols
|
17
28
|
are provided with the package, primarily to serve as examples. The real goal
|
18
29
|
of EventMachine is to enable programs to easily interface with other programs
|
19
|
-
using TCP/IP, especially if custom protocols are required.
|
20
|
-
}
|
21
|
-
s.email = %q{garbagecat10@gmail.com}
|
22
|
-
s.extensions = ["ext/extconf.rb", "ext/fastfilereader/extconf.rb"]
|
23
|
-
s.files = [".gitignore", "README", "Rakefile", "docs/COPYING", "docs/ChangeLog", "docs/DEFERRABLES", "docs/EPOLL", "docs/GNU", "docs/INSTALL", "docs/KEYBOARD", "docs/LEGAL", "docs/LIGHTWEIGHT_CONCURRENCY", "docs/PURE_RUBY", "docs/RELEASE_NOTES", "docs/SMTP", "docs/SPAWNED_PROCESSES", "docs/TODO", "eventmachine.gemspec", "examples/ex_channel.rb", "examples/ex_queue.rb", "examples/helper.rb", "ext/binder.cpp", "ext/binder.h", "ext/cmain.cpp", "ext/cplusplus.cpp", "ext/ed.cpp", "ext/ed.h", "ext/em.cpp", "ext/em.h", "ext/emwin.cpp", "ext/emwin.h", "ext/epoll.cpp", "ext/epoll.h", "ext/eventmachine.h", "ext/eventmachine_cpp.h", "ext/extconf.rb", "ext/fastfilereader/extconf.rb", "ext/fastfilereader/mapper.cpp", "ext/fastfilereader/mapper.h", "ext/fastfilereader/rubymain.cpp", "ext/files.cpp", "ext/files.h", "ext/kb.cpp", "ext/page.cpp", "ext/page.h", "ext/pipe.cpp", "ext/project.h", "ext/rubymain.cpp", "ext/sigs.cpp", "ext/sigs.h", "ext/ssl.cpp", "ext/ssl.h", "java/.classpath", "java/.project", "java/src/com/rubyeventmachine/EmReactor.java", "java/src/com/rubyeventmachine/EmReactorException.java", "java/src/com/rubyeventmachine/EventableChannel.java", "java/src/com/rubyeventmachine/EventableDatagramChannel.java", "java/src/com/rubyeventmachine/EventableSocketChannel.java", "java/src/com/rubyeventmachine/application/Application.java", "java/src/com/rubyeventmachine/application/Connection.java", "java/src/com/rubyeventmachine/application/ConnectionFactory.java", "java/src/com/rubyeventmachine/application/DefaultConnectionFactory.java", "java/src/com/rubyeventmachine/application/PeriodicTimer.java", "java/src/com/rubyeventmachine/application/Timer.java", "java/src/com/rubyeventmachine/tests/ApplicationTest.java", "java/src/com/rubyeventmachine/tests/ConnectTest.java", "java/src/com/rubyeventmachine/tests/EMTest.java", "java/src/com/rubyeventmachine/tests/TestDatagrams.java", "java/src/com/rubyeventmachine/tests/TestServers.java", "java/src/com/rubyeventmachine/tests/TestTimers.java", "lib/em/buftok.rb", "lib/em/callback.rb", "lib/em/channel.rb", "lib/em/connection.rb", "lib/em/deferrable.rb", "lib/em/file_watch.rb", "lib/em/future.rb", "lib/em/messages.rb", "lib/em/process_watch.rb", "lib/em/processes.rb", "lib/em/protocols.rb", "lib/em/protocols/header_and_content.rb", "lib/em/protocols/httpclient.rb", "lib/em/protocols/httpclient2.rb", "lib/em/protocols/line_and_text.rb", "lib/em/protocols/linetext2.rb", "lib/em/protocols/memcache.rb", "lib/em/protocols/object_protocol.rb", "lib/em/protocols/postgres3.rb", "lib/em/protocols/saslauth.rb", "lib/em/protocols/smtpclient.rb", "lib/em/protocols/smtpserver.rb", "lib/em/protocols/socks4.rb", "lib/em/protocols/stomp.rb", "lib/em/protocols/tcptest.rb", "lib/em/queue.rb", "lib/em/spawnable.rb", "lib/em/streamer.rb", "lib/em/timers.rb", "lib/em/version.rb", "lib/eventmachine.rb", "lib/evma.rb", "lib/evma/callback.rb", "lib/evma/container.rb", "lib/evma/factory.rb", "lib/evma/protocol.rb", "lib/evma/reactor.rb", "lib/jeventmachine.rb", "lib/pr_eventmachine.rb", "setup.rb", "tasks/cpp.rake_example", "tests/client.crt", "tests/client.key", "tests/test_attach.rb", "tests/test_basic.rb", "tests/test_channel.rb", "tests/test_connection_count.rb", "tests/test_defer.rb", "tests/test_epoll.rb", "tests/test_error_handler.rb", "tests/test_errors.rb", "tests/test_exc.rb", "tests/test_file_watch.rb", "tests/test_futures.rb", "tests/test_get_sock_opt.rb", "tests/test_handler_check.rb", "tests/test_hc.rb", "tests/test_httpclient.rb", "tests/test_httpclient2.rb", "tests/test_inactivity_timeout.rb", "tests/test_kb.rb", "tests/test_ltp.rb", "tests/test_ltp2.rb", "tests/test_next_tick.rb", "tests/test_object_protocol.rb", "tests/test_pause.rb", "tests/test_pending_connect_timeout.rb", "tests/test_process_watch.rb", "tests/test_processes.rb", "tests/test_proxy_connection.rb", "tests/test_pure.rb", "tests/test_queue.rb", "tests/test_running.rb", "tests/test_sasl.rb", "tests/test_send_file.rb", "tests/test_servers.rb", "tests/test_smtpclient.rb", "tests/test_smtpserver.rb", "tests/test_spawn.rb", "tests/test_ssl_args.rb", "tests/test_ssl_methods.rb", "tests/test_ssl_verify.rb", "tests/test_timers.rb", "tests/test_ud.rb", "tests/testem.rb", "web/whatis"]
|
24
|
-
s.homepage = %q{http://rubyeventmachine.com}
|
25
|
-
s.rdoc_options = ["--title", "EventMachine", "--main", "README", "--line-numbers", "-x", "lib/em/version", "-x", "lib/emva", "-x", "lib/evma/", "-x", "lib/pr_eventmachine", "-x", "lib/jeventmachine"]
|
26
|
-
s.require_paths = ["lib"]
|
27
|
-
s.rubyforge_project = %q{eventmachine}
|
28
|
-
s.rubygems_version = %q{1.3.5}
|
29
|
-
s.summary = %q{Ruby/EventMachine library}
|
30
|
-
|
31
|
-
if s.respond_to? :specification_version then
|
32
|
-
current_version = Gem::Specification::CURRENT_SPECIFICATION_VERSION
|
33
|
-
s.specification_version = 3
|
30
|
+
using TCP/IP, especially if custom protocols are required."
|
34
31
|
|
35
|
-
|
36
|
-
|
37
|
-
end
|
38
|
-
else
|
39
|
-
end
|
32
|
+
s.rdoc_options = ["--title", "EventMachine", "--main", "README.md", "-x", "lib/em/version", "-x", "lib/jeventmachine"]
|
33
|
+
s.extra_rdoc_files = ["README.md"] + `git ls-files -- docs/*`.split("\n")
|
40
34
|
end
|
@@ -0,0 +1,18 @@
|
|
1
|
+
#!/usr/bin/env ruby
|
2
|
+
|
3
|
+
require 'rubygems' # or use Bundler.setup
|
4
|
+
require 'eventmachine'
|
5
|
+
|
6
|
+
class EchoServer < EM::Connection
|
7
|
+
def receive_data(data)
|
8
|
+
send_data(data)
|
9
|
+
end
|
10
|
+
end
|
11
|
+
|
12
|
+
EventMachine.run do
|
13
|
+
# hit Control + C to stop
|
14
|
+
Signal.trap("INT") { EventMachine.stop }
|
15
|
+
Signal.trap("TERM") { EventMachine.stop }
|
16
|
+
|
17
|
+
EventMachine.start_server("0.0.0.0", 10000, EchoServer)
|
18
|
+
end
|