EventMachine provides a fast, lightweight framework for implementing Ruby programs that can use the network to communicate with other processes. Using EventMachine, Ruby programmers can easily connect to remote servers and act as servers themselves. EventMachine does not supplant the Ruby IP libraries. It does provide an alternate technique for those applications requiring better performance, scalability, and discipline over the behavior of network sockets, than is easily obtainable using the built-in libraries, especially in applications which are structurally well-suited for the event-driven programming model.
EventMachine provides a perpetual event-loop which your programs can start and stop. Within the event loop, TCP network connections are initiated and accepted, based on EventMachine methods called by your program. You also define callback methods which are called by EventMachine when events of interest occur within the event-loop.
User programs will be called back when the following events occur:
When the event loop accepts network connections from remote peers
When data is received from network connections
When connections are closed, either by the local or the remote side
When user-defined timers expire
Here’s a fully-functional echo server implemented in EventMachine:
require 'eventmachine' module EchoServer def post_init puts "-- someone connected to the echo server!" end def receive_data data send_data ">>>you sent: #{data}" close_connection if data =~ /quit/i end def unbind puts "-- someone disconnected from the echo server!" end end EventMachine::run { EventMachine::start_server "127.0.0.1", 8081, EchoServer }
What’s going on here? Well, we have defined the module EchoServer to implement the semantics of the echo protocol (more about that shortly). The last three lines invoke the event-machine itself, which runs forever unless one of your callbacks terminates it. The block that you supply to EventMachine::run contains code that runs immediately after the event machine is initialized and before it starts looping. This is the place to open up a TCP server by specifying the address and port it will listen on, together with the module that will process the data.
Our EchoServer is extremely simple as the echo protocol doesn’t require much work. Basically you want to send back to the remote peer whatever data it sends you. We’ll dress it up with a little extra text to make it interesting. Also, we’ll close the connection in case the received data contains the word “quit.“
So what about this module EchoServer? Well, whenever a network connection (either a client or a server) starts up, EventMachine instantiates an anonymous class, that your module has been mixed into. Exactly one of these class instances is created for each connection. Whenever an event occurs on a given connection, its corresponding object automatically calls specific instance methods which your module may redefine. The code in your module always runs in the context of a class instance, so you can create instance variables as you wish and they will be carried over to other callbacks made on that same connection.
Looking back up at EchoServer, you can see that we’ve defined the method receive_data which (big surprise) is called whenever data has been received from the remote end of the connection. Very simple. We get the data (a String object) and can do whatever we wish with it. In this case, we use the method send_data to return the received data to the caller, with some extra text added in. And if the user sends the word “quit,” we’ll close the connection with (naturally) close_connection. (Notice that closing the connection doesn’t terminate the processing loop, or change the fact that your echo server is still accepting connections!)
Would it be useful for EventMachine to incorporate the Observer pattern and make use of the corresponding Ruby observer package? Interesting thought.
Utility method for coercing arguments to an object that responds to # Accepts an object and a method name to send to, or a block, or an object that responds to call.
cb = EM.Callback{ |msg| puts(msg) } cb.call('hello world') cb = EM.Callback(Object, :puts) cb.call('hello world') cb = EM.Callback(proc{ |msg| puts(msg) }) cb.call('hello world')
# File lib/em/callback.rb, line 15 15: def self.Callback(object = nil, method = nil, &blk) 16: if object && method 17: lambda { |*args| object.send method, *args } 18: else 19: if object.respond_to? :call 20: object 21: else 22: blk || raise(ArgumentError) 23: end 24: end 25: end
EventMachine#add_periodic_timer adds a periodic timer to the event loop. It takes the same parameters as the one-shot timer method, EventMachine#add_timer. This method schedules execution of the given block repeatedly, at intervals of time at least as great as the number of seconds given in the first parameter to the call.
The following sample program will write a dollar-sign to stderr every five seconds. (Of course if the program defined network clients and/or servers, they would be doing their work while the periodic timer is counting off.)
EventMachine::run { EventMachine::add_periodic_timer( 5 ) { $stderr.write "$" } }
Also see EventMachine::PeriodicTimer
# File lib/eventmachine.rb, line 400 400: def self.add_periodic_timer *args, &block 401: interval = args.shift 402: code = args.shift || block 403: 404: EventMachine::PeriodicTimer.new(interval, code) 405: end
EventMachine#add_timer adds a one-shot timer to the event loop. Call it with one or two parameters. The first parameters is a delay-time expressed in seconds (not milliseconds). The second parameter, if present, must be a proc object. If a proc object is not given, then you can also simply pass a block to the method call.
EventMachine#add_timer may be called from the block passed to EventMachine#run or from any callback method. It schedules execution of the proc or block passed to add_timer, after the passage of an interval of time equal to at least the number of seconds specified in the first parameter to the call.
EventMachine#add_timer is a non-blocking call. Callbacks can and will be called during the interval of time that the timer is in effect. There is no built-in limit to the number of timers that can be outstanding at any given time.
This example shows how easy timers are to use. Observe that two timers are initiated simultaneously. Also, notice that the event loop will continue to run even after the second timer event is processed, since there was no call to EventMachine#stop_event_loop. There will be no activity, of course, since no network clients or servers are defined. Stop the program with Ctrl-C.
EventMachine::run { puts "Starting the run now: #{Time.now}" EventMachine::add_timer 5, proc { puts "Executing timer event: #{Time.now}" } EventMachine::add_timer( 10 ) { puts "Executing timer event: #{Time.now}" } }
Also see EventMachine::Timer
# File lib/eventmachine.rb, line 370 370: def self.add_timer *args, &block 371: interval = args.shift 372: code = args.shift || block 373: if code 374: # check too many timers! 375: s = add_oneshot_timer((interval.to_f * 1000).to_i) 376: @timers[s] = code 377: s 378: end 379: end
Attaches an IO object or file descriptor to the eventloop as a regular connection. The file descriptor will be set as non-blocking, and EventMachine will process receive_data and send_data events on it as it would for any other connection.
To watch a fd instead, use EventMachine::watch, which will not alter the state of the socket and fire notify_readable and notify_writable events instead.
# File lib/eventmachine.rb, line 778 778: def EventMachine::attach io, handler=nil, *args, &blk 779: attach_io io, false, handler, *args, &blk 780: end
EventMachine::bind_connect is like EventMachine::connect, but allows for a local address/port to bind the connection to.
# File lib/eventmachine.rb, line 697 697: def self.bind_connect bind_addr, bind_port, server, port=nil, handler=nil, *args 698: begin 699: port = Integer(port) 700: rescue ArgumentError, TypeError 701: # there was no port, so server must be a unix domain socket 702: # the port argument is actually the handler, and the handler is one of the args 703: args.unshift handler if handler 704: handler = port 705: port = nil 706: end if port 707: 708: klass = klass_from_handler(Connection, handler, *args) 709: 710: s = if port 711: if bind_addr 712: bind_connect_server bind_addr, bind_port.to_i, server, port 713: else 714: connect_server server, port 715: end 716: else 717: connect_unix_server server 718: end 719: 720: c = klass.new s, *args 721: @conns[s] = c 722: block_given? and yield c 723: c 724: end
Cancel a timer using its signature. You can also use EventMachine::Timer#cancel
# File lib/eventmachine.rb, line 409 409: def self.cancel_timer timer_or_sig 410: if timer_or_sig.respond_to? :cancel 411: timer_or_sig.cancel 412: else 413: @timers[timer_or_sig] = false if @timers.has_key?(timer_or_sig) 414: end 415: end
EventMachine#connect initiates a TCP connection to a remote server and sets up event-handling for the connection. You can call EventMachine#connect in the block supplied to EventMachine#run or in any callback method.
EventMachine#connect takes the IP address (or hostname) and port of the remote server you want to connect to. It also takes an optional handler Module which you must define, that contains the callbacks that will be invoked by the event loop on behalf of the connection.
See the description of EventMachine#start_server for a discussion of the handler Module. All of the details given in that description apply for connections created with EventMachine#connect.
Here’s a program which connects to a web server, sends a naive request, parses the HTTP header of the response, and then (antisocially) ends the event loop, which automatically drops the connection (and incidentally calls the connection’s unbind method).
module DumbHttpClient def post_init send_data "GET / HTTP/1.1\r\nHost: _\r\n\r\n" @data = "" @parsed = false end def receive_data data @data << data if !@parsed and @data =~ /[\n][\r]*[\n]/m @parsed = true puts "RECEIVED HTTP HEADER:" $`.each {|line| puts ">>> #{line}" } puts "Now we'll terminate the loop, which will also close the connection" EventMachine::stop_event_loop end end def unbind puts "A connection has terminated" end end EventMachine::run { EventMachine::connect "www.bayshorenetworks.com", 80, DumbHttpClient } puts "The event loop has ended"
There are times when it’s more convenient to define a protocol handler as a Class rather than a Module. Here’s how to do this:
class MyProtocolHandler < EventMachine::Connection def initialize *args super # whatever else you want to do here end #.......your other class code end
If you do this, then an instance of your class will be instantiated to handle every network connection created by your code or accepted by servers that you create. If you redefine # in your protocol-handler class, your # method will be called inside the call to # that you will make in your # method (if you provide one).
# File lib/eventmachine.rb, line 691 691: def self.connect server, port=nil, handler=nil, *args, &blk 692: bind_connect nil, nil, server, port, handler, *args, &blk 693: end
Make a connection to a Unix-domain socket. This is not implemented on Windows platforms. The parameter socketname is a String which identifies the Unix-domain socket you want to connect to. socketname is the name of a file on your local system, and in most cases is a fully-qualified path name. Make sure that your process has enough local permissions to open the Unix-domain socket. See also the documentation for #. This method behaves like # in all respects except for the fact that it connects to a local Unix-domain socket rather than a TCP socket.
Note that this method is simply an alias for #, which can connect to both TCP and Unix-domain sockets
# File lib/eventmachine.rb, line 845 845: def self.connect_unix_domain socketname, *args, &blk 846: connect socketname, *args, &blk 847: end
Returns the total number of connections (file descriptors) currently held by the reactor. Note that a tick must pass after the ‘initiation’ of a connection for this number to increment. It’s usually accurate, but don’t rely on the exact precision of this number unless you really know EM internals.
For example, $count will be 0 in this case:
EM.run { EM.connect("rubyeventmachine.com", 80) $count = EM.connection_count }
In this example, $count will be 1 since the connection has been established in the next loop of the reactor.
EM.run { EM.connect("rubyeventmachine.com", 80) EM.next_tick { $count = EM.connection_count } }
# File lib/eventmachine.rb, line 974 974: def self.connection_count 975: self.get_connection_count 976: end
# is for integrating blocking operations into EventMachine’s control flow. Call # with one or two blocks, as shown below (the second block is optional):
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 # 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 # (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.
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.]
# File lib/eventmachine.rb, line 1043 1043: def self.defer op = nil, callback = nil, &blk 1044: unless @threadpool 1045: require 'thread' 1046: @threadpool = [] 1047: @threadqueue = ::Queue.new 1048: @resultqueue = ::Queue.new 1049: spawn_threadpool 1050: end 1051: 1052: @threadqueue << [op||blk,callback] 1053: end
disable_proxy takes just one argument, a Connection that has proxying enabled via enable_proxy. Calling this method will remove that functionality and your connection will begin receiving data via receive_data again.
# File lib/eventmachine.rb, line 1379 1379: def self.disable_proxy(from) 1380: EM::stop_proxy(from.signature) 1381: end
enable_proxy allows for direct writing of incoming data back out to another descriptor, at the C++ level in the reactor. This is especially useful for proxies where high performance is required. Propogating data from a server response all the way up to Ruby, and then back down to the reactor to be sent back to the client, is often unnecessary and incurs a significant performance decrease.
The two arguments are Connections, ‘from’ and ‘to’. ‘from’ is the connection whose inbound data you want relayed back out. ‘to’ is the connection to write it to.
Once you call this method, the ‘from’ connection will no longer get receive_data callbacks from the reactor, except in the case that ‘to’ connection has already closed when attempting to write to it. You can see in the example, that proxy_target_unbound will be called when this occurs. After that, further incoming data will be passed into receive_data as normal.
Note also that this feature supports different types of descriptors - TCP, UDP, and pipes. You can relay data from one kind to another.
Example:
module ProxyConnection def initialize(client, request) @client, @request = client, request end def post_init EM::enable_proxy(self, @client) end def connection_completed send_data @request end def proxy_target_unbound close_connection end def unbind @client.close_connection_after_writing end end module ProxyServer def receive_data(data) (@buf ||= "") << data if @buf =~ /\r\n\r\n/ # all http headers received EM.connect("10.0.0.15", 80, ProxyConnection, self, data) end end end EM.run { EM.start_server("127.0.0.1", 8080, ProxyServer) }
# File lib/eventmachine.rb, line 1372 1372: def self.enable_proxy(from, to, bufsize=0) 1373: EM::start_proxy(from.signature, to.signature, bufsize) 1374: end
Catch-all for errors raised during event loop callbacks.
EM.error_handler{ |e| puts "Error raised during event loop: #{e.message}" }
# File lib/eventmachine.rb, line 1312 1312: def self.error_handler cb = nil, &blk 1313: if cb or blk 1314: @error_handler = cb || blk 1315: elsif instance_variable_defined? :@error_handler 1316: remove_instance_variable :@error_handler 1317: end 1318: end
fork_reactor forks a new process and calls EM#run inside of it, passing your block.
# File lib/eventmachine.rb, line 322 322: def self.fork_reactor &block 323: Kernel.fork do 324: if self.reactor_running? 325: self.stop_event_loop 326: self.release_machine 327: self.instance_variable_set( '@reactor_running', false ) 328: end 329: self.run block 330: end 331: end
Gets the current maximum number of allowed timers
# File lib/eventmachine.rb, line 950 950: def self.get_max_timers 951: get_max_timer_count 952: end
Retrieve the heartbeat interval. This is how often EventMachine will check for dead connections that have had an InactivityTimeout set via Connection#set_comm_inactivity_timeout. Default is 2 seconds.
# File lib/eventmachine.rb, line 1386 1386: def self.heartbeat_interval 1387: EM::get_heartbeat_interval 1388: end
Set the heartbeat interval. This is how often EventMachine will check for dead connections that have had an InactivityTimeout set via Connection#set_comm_inactivity_timeout. Takes a Numeric number of seconds. Default is 2.
# File lib/eventmachine.rb, line 1393 1393: def self.heartbeat_interval= (time) 1394: EM::set_heartbeat_interval time.to_f 1395: end
Schedules a proc for execution immediately after the next “turn” through the reactor core. An advanced technique, this can be useful for improving memory management and/or application responsiveness, especially when scheduling large amounts of data for writing to a network connection. TODO, we need a FAQ entry on this subject.
# takes either a single argument (which must be a Proc) or a block.
# File lib/eventmachine.rb, line 1092 1092: def self.next_tick pr=nil, &block 1093: raise ArgumentError, "no proc or block given" unless ((pr && pr.respond_to?(:call)) or block) 1094: @next_tick_mutex.synchronize do 1095: (@next_tick_queue ||= []) << ( pr || block ) 1096: end 1097: signal_loopbreak if reactor_running? 1098: end
EventMachine#open_datagram_socket is for support of UDP-based protocols. Its usage is similar to that of EventMachine#start_server. It takes three parameters: an IP address (which must be valid on the machine which executes the method), a port number, and an optional Module name which will handle the data. This method will create a new UDP (datagram) socket and bind it to the address and port that you specify. The normal callbacks (see EventMachine#start_server) will be called as events of interest occur on the newly-created socket, but there are some differences in how they behave.
Connection#receive_data will be called when a datagram packet is received on the socket, but unlike TCP sockets, the message boundaries of the received data will be respected. In other words, if the remote peer sent you a datagram of a particular size, you may rely on Connection#receive_data to give you the exact data in the packet, with the original data length. Also observe that Connection#receive_data may be called with a zero-length data payload, since empty datagrams are permitted in UDP.
Connection#send_data is available with UDP packets as with TCP, but there is an important difference. Because UDP communications are connectionless, there is no implicit recipient for the packets you send. Ordinarily you must specify the recipient for each packet you send. However, EventMachine provides for the typical pattern of receiving a UDP datagram from a remote peer, performing some operation, and then sending one or more packets in response to the same remote peer. To support this model easily, just use Connection#send_data in the code that you supply for Connection:receive_data. EventMachine will provide an implicit return address for any messages sent to Connection#send_data within the context of a Connection#receive_data callback, and your response will automatically go to the correct remote peer. (TODO: Example-code needed!)
Observe that the port number that you supply to EventMachine#open_datagram_socket may be zero. In this case, EventMachine will create a UDP socket that is bound to an ephemeral (not well-known) port. This is not appropriate for servers that must publish a well-known port to which remote peers may send datagrams. But it can be useful for clients that send datagrams to other servers. If you do this, you will receive any responses from the remote servers through the normal Connection#receive_data callback. Observe that you will probably have issues with firewalls blocking the ephemeral port numbers, so this technique is most appropriate for LANs. (TODO: Need an example!)
If you wish to send datagrams to arbitrary remote peers (not necessarily ones that have sent data to which you are responding), then see Connection#send_datagram.
DO NOT call send_data from a datagram socket outside of a # method. Use #. If you do use # outside of a # method, you’ll get a confusing error because there is no “peer,” as # requires. (Inside of #, # “fakes” the peer as described above.)
# File lib/eventmachine.rb, line 913 913: def self.open_datagram_socket address, port, handler=nil, *args 914: klass = klass_from_handler(Connection, handler, *args) 915: s = open_udp_socket address, port.to_i 916: c = klass.new s, *args 917: @conns[s] = c 918: block_given? and yield c 919: c 920: end
(Experimental)
# File lib/eventmachine.rb, line 1191 1191: def self.open_keyboard handler=nil, *args 1192: klass = klass_from_handler(Connection, handler, *args) 1193: 1194: s = read_keyboard 1195: c = klass.new s, *args 1196: @conns[s] = c 1197: block_given? and yield c 1198: c 1199: end
Run an external process. This does not currently work on Windows.
module RubyCounter def post_init # count up to 5 send_data "5\n" end def receive_data data puts "ruby sent me: #{data}" end def unbind puts "ruby died with exit status: #{get_status.exitstatus}" end end EM.run{ EM.popen("ruby -e' $stdout.sync = true; gets.to_i.times{ |i| puts i+1; sleep 1 } '", RubyCounter) }
Also see EventMachine::DeferrableChildProcess and EventMachine.system
# File lib/eventmachine.rb, line 1161 1161: def self.popen cmd, handler=nil, *args 1162: klass = klass_from_handler(Connection, handler, *args) 1163: w = Shellwords::shellwords( cmd ) 1164: w.unshift( w.first ) if w.first 1165: s = invoke_popen( w ) 1166: c = klass.new s, *args 1167: @conns[s] = c 1168: yield(c) if block_given? 1169: c 1170: end
Tells you whether the EventMachine reactor loop is currently running. Returns true or false. Useful when writing libraries that want to run event-driven code, but may be running in programs that are already event-driven. In such cases, if EventMachine#reactor_running? returns false, your code can invoke EventMachine#run and run your application code inside the block passed to that method. If EventMachine#reactor_running? returns true, just execute your event-aware code.
This method is necessary because calling EventMachine#run inside of another call to EventMachine#run generates a fatal error.
# File lib/eventmachine.rb, line 1183 1183: def self.reactor_running? 1184: (@reactor_running || false) 1185: end
Returns true if the calling thread is the same thread as the reactor.
# File lib/eventmachine.rb, line 301 301: def self.reactor_thread? 302: Thread.current == @reactor_thread 303: end
EventMachine::run initializes and runs an event loop. This method only returns if user-callback code calls stop_event_loop. Use the supplied block to define your clients and servers. The block is called by EventMachine::run immediately after initializing its internal event loop but before running the loop. Therefore this block is the right place to call start_server if you want to accept connections from remote clients.
For programs that are structured as servers, it’s usually appropriate to start an event loop by calling EventMachine::run, and let it run forever. It’s also possible to use EventMachine::run to make a single client-connection to a remote server, process the data flow from that single connection, and then call stop_event_loop to force EventMachine::run to return. Your program will then continue from the point immediately following the call to EventMachine::run.
You can of course do both client and servers simultaneously in the same program. One of the strengths of the event-driven programming model is that the handling of network events on many different connections will be interleaved, and scheduled according to the actual events themselves. This maximizes efficiency.
See EventMachine.start_server
See EventMachine.connect
# File lib/eventmachine.rb, line 236 236: def self.run blk=nil, tail=nil, &block 237: @tails ||= [] 238: tail and @tails.unshift(tail) 239: 240: if reactor_running? 241: (b = blk || block) and b.call # next_tick(b) 242: else 243: @conns = {} 244: @acceptors = {} 245: @timers = {} 246: @wrapped_exception = nil 247: @next_tick_queue ||= [] 248: begin 249: @reactor_running = true 250: initialize_event_machine 251: (b = blk || block) and add_timer(0, b) 252: if @next_tick_queue && !@next_tick_queue.empty? 253: add_timer(0) { signal_loopbreak } 254: end 255: @reactor_thread = Thread.current 256: run_machine 257: ensure 258: until @tails.empty? 259: @tails.pop.call 260: end 261: 262: begin 263: release_machine 264: ensure 265: if @threadpool 266: @threadpool.each { |t| t.exit } 267: @threadpool.each do |t| 268: next unless t.alive? 269: # ruby 1.9 has no kill! 270: t.respond_to?(:kill!) ? t.kill! : t.kill 271: end 272: @threadqueue = nil 273: @resultqueue = nil 274: @threadpool = nil 275: end 276: 277: @next_tick_queue = nil 278: end 279: @reactor_running = false 280: @reactor_thread = nil 281: end 282: 283: raise @wrapped_exception if @wrapped_exception 284: end 285: end
Sugars a common use case. Will pass the given block to #, but will terminate the reactor loop and exit the function as soon as the code in the block completes. (Normally, # keeps running indefinitely, even after the block supplied to it finishes running, until user code calls #.)
# File lib/eventmachine.rb, line 292 292: def self.run_block &block 293: pr = proc { 294: block.call 295: EventMachine::stop 296: } 297: run(&pr) 298: end
Runs the given callback on the reactor thread, or immediately if called from the reactor thread. Accepts the same arguments as EM::Callback
# File lib/eventmachine.rb, line 307 307: def self.schedule(*a, &b) 308: cb = Callback(*a, &b) 309: if reactor_running? && reactor_thread? 310: cb.call 311: else 312: next_tick { cb.call } 313: end 314: end
Sets the maximum number of file or socket descriptors that your process may open. You can pass this method an integer specifying the new size of the descriptor table. Returns the new descriptor-table size, which may be less than the number you requested. If you call this method with no arguments, it will simply return the current size of the descriptor table without attempting to change it.
The new limit on open descriptors ONLY applies to sockets and other descriptors that belong to EventMachine. It has NO EFFECT on the number of descriptors you can create in ordinary Ruby code.
Not available on all platforms. Increasing the number of descriptors beyond its default limit usually requires superuser privileges. (See # for a way to drop superuser privileges while your program is running.)
# File lib/eventmachine.rb, line 1131 1131: def self.set_descriptor_table_size n_descriptors=nil 1132: EventMachine::set_rlimit_nofile n_descriptors 1133: end
A wrapper over the setuid system call. Particularly useful when opening a network server on a privileged port because you can use this call to drop privileges after opening the port. Also very useful after a call to #, which generally requires that you start your process with root privileges.
This method has no effective implementation on Windows or in the pure-Ruby implementation of EventMachine. Call # by passing it a string containing the effective name of the user whose privilege-level your process should attain. This method is intended for use in enforcing security requirements, consequently it will throw a fatal error and end your program if it fails.
# File lib/eventmachine.rb, line 1112 1112: def self.set_effective_user username 1113: EventMachine::setuid_string username 1114: end
Sets the maximum number of timers and periodic timers that may be outstanding at any given time. You only need to call # if you need more than the default number of timers, which on most platforms is 1000. Call this method before calling EventMachine#run.
# File lib/eventmachine.rb, line 944 944: def self.set_max_timers ct 945: set_max_timer_count ct 946: end
For advanced users. This function sets the default timer granularity, which by default is slightly smaller than 100 milliseconds. Call this function to set a higher or lower granularity. The function affects the behavior of # and #. Most applications will not need to call this function.
The argument is a number of milliseconds. Avoid setting the quantum to very low values because that may reduce performance under some extreme conditions. We recommend that you not set a quantum lower than 10.
You may only call this function while an EventMachine loop is running (that is, after a call to EventMachine#run and before a subsequent call to EventMachine#stop).
# File lib/eventmachine.rb, line 935 935: def self.set_quantum mills 936: set_timer_quantum mills.to_i 937: end
Spawn an erlang-style process
# File lib/em/spawnable.rb, line 72 72: def self.spawn &block 73: s = SpawnedProcess.new 74: s.set_receiver block 75: s 76: end
EventMachine::start_server initiates a TCP server (socket acceptor) on the specified IP address and port. The IP address must be valid on the machine where the program runs, and the process must be privileged enough to listen on the specified port (on Unix-like systems, superuser privileges are usually required to listen on any port lower than 1024). Only one listener may be running on any given address/port combination. start_server will fail if the given address and port are already listening on the machine, either because of a prior call to start_server or some unrelated process running on the machine. If start_server succeeds, the new network listener becomes active immediately and starts accepting connections from remote peers, and these connections generate callback events that are processed by the code specified in the handler parameter to start_server.
The optional handler which is passed to start_server is the key to EventMachine’s ability to handle particular network protocols. The handler parameter passed to start_server must be a Ruby Module that you must define. When the network server that is started by start_server accepts a new connection, it instantiates a new object of an anonymous class that is inherited from EventMachine::Connection, into which the methods from your handler have been mixed. Your handler module may redefine any of the methods in EventMachine::Connection in order to implement the specific behavior of the network protocol.
Callbacks invoked in response to network events always take place within the execution context of the object derived from EventMachine::Connection extended by your handler module. There is one object per connection, and all of the callbacks invoked for a particular connection take the form of instance methods called against the corresponding EventMachine::Connection object. Therefore, you are free to define whatever instance variables you wish, in order to contain the per-connection state required by the network protocol you are implementing.
start_server is often called inside the block passed to EventMachine::run, but it can be called from any EventMachine callback. start_server will fail unless the EventMachine event loop is currently running (which is why it’s often called in the block suppled to EventMachine::run).
You may call start_server any number of times to start up network listeners on different address/port combinations. The servers will all run simultaneously. More interestingly, each individual call to start_server can specify a different handler module and thus implement a different network protocol from all the others.
Here is an example of a server that counts lines of input from the remote peer and sends back the total number of lines received, after each line. Try the example with more than one client connection opened via telnet, and you will see that the line count increments independently on each of the client connections. Also very important to note, is that the handler for the receive_data function, which our handler redefines, may not assume that the data it receives observes any kind of message boundaries. Also, to use this example, be sure to change the server and port parameters to the start_server call to values appropriate for your environment.
require 'rubygems' require 'eventmachine' module LineCounter MaxLinesPerConnection = 10 def post_init puts "Received a new connection" @data_received = "" @line_count = 0 end def receive_data data @data_received << data while @data_received.slice!( /^[^\n]*[\n]/m ) @line_count += 1 send_data "received #{@line_count} lines so far\r\n" @line_count == MaxLinesPerConnection and close_connection_after_writing end end end EventMachine::run { host,port = "192.168.0.100", 8090 EventMachine::start_server host, port, LineCounter puts "Now accepting connections on address #{host}, port #{port}..." EventMachine::add_periodic_timer( 10 ) { $stderr.write "*" } }
# File lib/eventmachine.rb, line 558 558: def self.start_server server, port=nil, handler=nil, *args, &block 559: begin 560: port = Integer(port) 561: rescue ArgumentError, TypeError 562: # there was no port, so server must be a unix domain socket 563: # the port argument is actually the handler, and the handler is one of the args 564: args.unshift handler if handler 565: handler = port 566: port = nil 567: end if port 568: 569: klass = klass_from_handler(Connection, handler, *args) 570: 571: s = if port 572: start_tcp_server server, port 573: else 574: start_unix_server server 575: end 576: @acceptors[s] = [klass,args,block] 577: s 578: end
Start a Unix-domain server
Note that this is an alias for EventMachine::start_server, which can be used to start both TCP and Unix-domain servers
# File lib/eventmachine.rb, line 594 594: def self.start_unix_domain_server filename, *args, &block 595: start_server filename, *args, &block 596: end
stop_event_loop may called from within a callback method while EventMachine’s processing loop is running. It causes the processing loop to stop executing, which will cause all open connections and accepting servers to be run down and closed. Callbacks for connection-termination will be called as part of the processing of stop_event_loop. (There currently is no option to panic-stop the loop without closing connections.) When all of this processing is complete, the call to EventMachine::run which started the processing loop will return and program flow will resume from the statement following EventMachine::run call.
require 'rubygems' require 'eventmachine' module Redmond def post_init puts "We're sending a dumb HTTP request to the remote peer." send_data "GET / HTTP/1.1\r\nHost: www.microsoft.com\r\n\r\n" end def receive_data data puts "We received #{data.length} bytes from the remote peer." puts "We're going to stop the event loop now." EventMachine::stop_event_loop end def unbind puts "A connection has terminated." end end puts "We're starting the event loop now." EventMachine::run { EventMachine::connect "www.microsoft.com", 80, Redmond } puts "The event loop has stopped."
This program will produce approximately the following output:
We're starting the event loop now. We're sending a dumb HTTP request to the remote peer. We received 1440 bytes from the remote peer. We're going to stop the event loop now. A connection has terminated. The event loop has stopped.
# File lib/eventmachine.rb, line 468 468: def self.stop_event_loop 469: EventMachine::stop 470: end
Stop a TCP server socket that was started with EventMachine#start_server.
# File lib/eventmachine.rb, line 586 586: def self.stop_server signature 587: EventMachine::stop_tcp_server signature 588: end
EM::system is a simple wrapper for EM::popen. It is similar to Kernel::system, but requires a single string argument for the command and performs no shell expansion.
The block or proc passed to EM::system is called with two arguments: the output generated by the command, and a Process::Status that contains information about the command’s execution.
EM.run{ EM.system('ls'){ |output,status| puts output if status.exitstatus == 0 } }
You can also supply an additional proc to send some data to the process:
EM.run{ EM.system('sh', proc{ |process| process.send_data("echo hello\n") process.send_data("exit\n") }, proc{ |out,status| puts(out) }) }
Like EventMachine.popen, EventMachine.system currently does not work on windows. It returns the pid of the spawned process.
# File lib/em/processes.rb, line 108 108: def EventMachine::system cmd, *args, &cb 109: cb ||= args.pop if args.last.is_a? Proc 110: init = args.pop if args.last.is_a? Proc 111: 112: # merge remaining arguments into the command 113: cmd = ([cmd] + args.map{|a|a.to_s.dump}).join(' ') 114: 115: EM.get_subprocess_pid(EM.popen(cmd, SystemCmd, cb) do |c| 116: init[c] if init 117: end.signature) 118: end
EventMachine::watch registers a given file descriptor or IO object with the eventloop. The file descriptor will not be modified (it will remain blocking or non-blocking).
The eventloop can be used to process readable and writable events on the file descriptor, using EventMachine::Connection#notify_readable= and EventMachine::Connection#notify_writable=
EventMachine::Connection#notify_readable? and EventMachine::Connection#notify_writable? can be used to check what events are enabled on the connection.
To detach the file descriptor, use EventMachine::Connection#detach
module SimpleHttpClient def notify_readable header = @io.readline if header == "\r\n" # detach returns the file descriptor number (fd == @io.fileno) fd = detach end rescue EOFError detach end def unbind EM.next_tick do # socket is detached from the eventloop, but still open data = @io.read end end end EM.run{ $sock = TCPSocket.new('site.com', 80) $sock.write("GET / HTTP/1.0\r\n\r\n") conn = EM.watch $sock, SimpleHttpClient conn.notify_readable = true }
# File lib/eventmachine.rb, line 768 768: def EventMachine::watch io, handler=nil, *args, &blk 769: attach_io io, true, handler, *args, &blk 770: end
EventMachine’s file monitoring API. Currently supported are the following events on individual files, using inotify on Linux systems, and kqueue for OSX/BSD:
File modified (written to)
File moved/renamed
File deleted
EventMachine::watch_file takes a filename and a handler Module containing your custom callback methods. This will setup the low level monitoring on the specified file, and create a new EventMachine::FileWatch object with your Module mixed in. FileWatch is a subclass of EM::Connection, so callbacks on this object work in the familiar way. The callbacks that will be fired by EventMachine are:
file_modified
file_moved
file_deleted
You can access the filename being monitored from within this object using FileWatch#path.
When a file is deleted, FileWatch#stop_watching will be called after your file_deleted callback, to clean up the underlying monitoring and remove EventMachine’s reference to the now-useless FileWatch. This will in turn call unbind, if you wish to use it.
The corresponding system-level Errno will be raised when attempting to monitor non-existent files, files with wrong permissions, or if an error occurs dealing with inotify/kqueue.
Make sure we have a file to monitor: $ echo "bar" > /tmp/foo module Handler def file_modified puts "#{path} modified" end def file_moved puts "#{path} moved" end def file_deleted puts "#{path} deleted" end def unbind puts "#{path} monitoring ceased" end end EM.kqueue = true if EM.kqueue? # file watching requires kqueue on OSX EM.run { EM.watch_file("/tmp/foo", Handler) } $ echo "baz" >> /tmp/foo => "/tmp/foo modified" $ mv /tmp/foo /tmp/oof => "/tmp/foo moved" $ rm /tmp/oof => "/tmp/foo deleted" => "/tmp/foo monitoring ceased"
Note that we have not implemented the ability to pick up on the new filename after a rename. Calling # will always return the filename you originally used.
# File lib/eventmachine.rb, line 1263 1263: def self.watch_file(filename, handler=nil, *args) 1264: klass = klass_from_handler(FileWatch, handler, *args) 1265: 1266: s = EM::watch_filename(filename) 1267: c = klass.new s, *args 1268: # we have to set the path like this because of how Connection.new works 1269: c.instance_variable_set("@path", filename) 1270: @conns[s] = c 1271: block_given? and yield c 1272: c 1273: end
EventMachine’s process monitoring API. Currently supported using kqueue for OSX/BSD.
module ProcessWatcher def process_exited put 'the forked child died!' end end pid = fork{ sleep } EM.run{ EM.watch_process(pid, ProcessWatcher) EM.add_timer(1){ Process.kill('TERM', pid) } }
# File lib/eventmachine.rb, line 1292 1292: def self.watch_process(pid, handler=nil, *args) 1293: pid = pid.to_i 1294: 1295: klass = klass_from_handler(ProcessWatch, handler, *args) 1296: 1297: s = EM::watch_pid(pid) 1298: c = klass.new s, *args 1299: # we have to set the path like this because of how Connection.new works 1300: c.instance_variable_set("@pid", pid) 1301: @conns[s] = c 1302: block_given? and yield c 1303: c 1304: end
# File lib/eventmachine.rb, line 1570 1570: def self.klass_from_handler(klass = Connection, handler = nil, *args) 1571: klass = if handler and handler.is_a?(Class) 1572: raise ArgumentError, "must provide module or subclass of #{klass.name}" unless klass >= handler 1573: handler 1574: elsif handler 1575: Class.new(klass){ include handler } 1576: else 1577: klass 1578: end 1579: 1580: arity = klass.instance_method(:initialize).arity 1581: expected = arity >= 0 ? arity : -(arity + 1) 1582: if (arity >= 0 and args.size != expected) or (arity < 0 and args.size < expected) 1583: raise ArgumentError, "wrong number of arguments for #{klass}#initialize (#{args.size} for #{expected})" 1584: end 1585: 1586: klass 1587: end
Disabled; run with --debug to generate this.
Generated with the Darkfish Rdoc Generator 1.1.6.