crusher-eventmachine 0.12.11

data/docs/LEGAL

@@ -0,0 +1,25 @@
+LEGAL NOTICE INFORMATION
+------------------------
+
+EventMachine is Copyright (C) 2006-07 by Francis Cianfrocca.
+
+EventMachine is copyrighted software owned by Francis Cianfrocca
+(blackhedd ... gmail.com). You may redistribute and/or modify this
+software as long as you comply with either the terms of the GPL
+(see the file GPL), or Ruby's license (see the file COPYING).
+
+Your use of all the files in this distribution is controlled by these
+license terms, except for those files specifically mentioned below:
+
+
+
+setup.rb
+	This file is Copyright (C) 2000-2005 by Minero Aoki
+	You can distribute/modify this file under the terms of
+	the GNU LGPL, Lesser General Public License version 2.1.
+
+
+lib/em/buftok.rb
+	This file is Copyright (C) 2007 by Tony Arcieri. This file is
+	covered by the terms of Ruby's License (see the file COPYING).
+

data/docs/LIGHTWEIGHT_CONCURRENCY

@@ -0,0 +1,130 @@
+EventMachine (EM) adds two different formalisms for lightweight concurrency to
+the Ruby programmer's toolbox: spawned processes and deferrables. This note
+will show you how to use them.
+
+
+=== What is Lightweight Concurrency?
+
+We use the term "Lightweight Concurrency" (LC) to refer to concurrency
+mechanisms that are lighter than Ruby threads. By "lighter," we mean: less
+resource-intensive in one or more dimensions, usually including memory and
+CPU usage. In general, you turn to LC in the hope of improving the
+performance and scalability of your programs.
+
+In addition to the two EventMachine mechanisms we will discuss here, Ruby
+has at least one other LC construct: Fibers, which are currently under
+development in Ruby 1.9.
+
+The technical feature that makes all of these LC mechanisms different from
+standard Ruby threads is that they are not scheduled automatically.
+
+When you create and run Ruby threads, you can assume (within certain
+constraints) that your threads will all be scheduled fairly by Ruby's runtime.
+Ruby itself is responsible for giving each of your threads its own share of
+the total runtime.
+
+But with LC, your program is responsible for causing different execution
+paths to run. In effect, your program has to act as a "thread scheduler."
+Scheduled entities in LC run to completion and are never preempted. The
+runtime system has far less work to do since it has no need to interrupt
+threads or to schedule them fairly. This is what makes LC lighter and faster.
+
+You'll learn exactly how LC scheduling works in practice as we work through
+specific examples.
+
+
+=== EventMachine Lightweight Concurrency
+
+Recall that EM provides a reactor loop that must be running in order for
+your programs to perform event-driven logic. An EM program typically has a
+structure like this:
+
+ require 'eventmachine'
+
+ # your initializations
+
+ EM.run {
+     # perform event-driven I/O here, including network clients,
+     # servers, timers, and thread-pool operations.
+ }
+
+ # your cleanup
+ # end of the program
+
+
+EventMachine#run executes the reactor loop, which causes your code to be
+called as events of interest to your program occur. The block you pass to
+EventMachine#run is executed right after the reactor loop starts, and is
+the right place to start socket acceptors, etc.
+
+Because the reactor loop runs constantly in an EM program (until it is
+stopped by a call to EventMachine#stop), it has the ability to schedule
+blocks of code for asynchronous execution. Unlike a pre-emptive thread
+scheduler, it's NOT able to interrupt code blocks while they execute. But
+the scheduling capability it does have is enough to enable lightweight
+concurrency.
+
+
+For information on Spawned Processes, see the separate document
+SPAWNED_PROCESSES.
+
+For information on Deferrables, see the separate document DEFERRABLES.
+
+
+=== [SIDEBAR]: I Heard That EventMachine Doesn't Work With Ruby Threads.
+
+This is incorrect. EM is fully interoperable with all versions of Ruby
+threads, and has been since its earliest releases.
+
+It's very true that EM encourages an "evented" (non-threaded) programming
+style. The specific benefits of event-driven programming are far better
+performance and scalability for well-written programs, and far easier
+debugging.
+
+The benefit of using threads for similar applications is a possibly more
+intuitive programming model, as well as the fact that threads are already
+familiar to most programmers. Also, bugs in threaded programs often fail
+to show up until programs go into production. These factors create the
+illusion that threaded programs are easier to write.
+
+However, some operations that occur frequently in professional-caliber
+applications simply can't be done without threads. (The classic example
+is making calls to database client-libraries that block on network I/O
+until they complete.)
+
+EventMachine not only allows the use of Ruby threads in these cases, but
+it even provides a built-in thread-pool object to make them easier to
+work with.
+
+You may have heard a persistent criticism that evented I/O is fundamentally
+incompatible with Ruby threads. It is true that some well-publicized attempts
+to incorporate event-handling libraries into Ruby were not successful. But
+EventMachine was designed from the ground up with Ruby compatibility in mind,
+so EM never suffered from the problems that defeated the earlier attempts.
+
+
+=== [SIDEBAR]: I Heard That EventMachine Doesn't Work Very Well On Windows.
+
+This too is incorrect. EventMachine is an extension written in C++ and Java,
+and therefore it requires compilation. Many Windows computers (and some Unix
+computers, especially in production environments) don't have a build stack.
+Attempting to install EventMachine on a machine without a compiler usually
+produces a confusing error.
+
+In addition, Ruby has a much-debated issue with Windows compiler versions.
+Ruby on Windows works best with Visual Studio 6, a compiler version that is
+long out-of-print, no longer supported by Microsoft, and difficult to obtain.
+(This problem is not specific to EventMachine.)
+
+Shortly after EventMachine was first released, the compiler issues led to
+criticism that EM was incompatible with Windows. Since that time, every
+EventMachine release has been supplied in a precompiled binary form for
+Windows users, that does not require you to compile the code yourself. EM
+binary Gems for Windows are compiled using Visual Studio 6.
+
+EventMachine does supply some advanced features (such as Linux EPOLL support,
+reduced-privilege operation, UNIX-domain sockets, etc.) that have no
+meaningful implementation on Windows. Apart from these special cases, all EM
+functionality (including lightweight concurrency) works perfectly well on
+Windows.
+

data/docs/PURE_RUBY

@@ -0,0 +1,75 @@
+EventMachine is supplied in three alternative versions.
+
+1) A version that includes a Ruby extension written in C++. This version requires compilation;
+2) A version for JRuby that contains a precompiled JAR file written in Java;
+3) A pure Ruby version that has no external dependencies and can run in any Ruby environment.
+
+The Java version of EventMachine is packaged in a distinct manner and must be installed using a
+special procedure. This version is described fully in a different document, and not considered
+further here.
+
+The C++ and pure-Ruby versions, however, are shipped in the same distribution. You use the same
+files (either tarball or Ruby gem) to install both of these versions.
+
+If you intend to use the C++ version, you must successfully compile EventMachine after you install it.
+(The gem installation attempts to perform this step automatically.)
+
+If you choose not to compile the EventMachine C++ extension, or if your compilation fails for any
+reason, you still have a fully-functional installation of the pure-Ruby version of EM.
+
+However, for technical reasons, a default EM installation (whether or not the compilation succeeds)
+will always assume that the compiled ("extension") implementation should be used.
+
+If you want your EM program to use the pure Ruby version, you must specifically request it. There
+are two ways to do this: by setting either a Ruby global variable, or an environment string.
+
+The following code will invoke the pure-Ruby implementation of EM:
+
+ $eventmachine_library = :pure_ruby
+ require 'eventmachine'
+
+ EM.library_type #=> "pure_ruby"
+
+Notice that this requires a code change and is not the preferred way to select pure Ruby, unless
+for some reason you are absolutely sure you will never want the compiled implementation.
+
+Setting the following environment string has the same effect:
+
+ export EVENTMACHINE_LIBRARY="pure_ruby"
+
+This technique gives you the flexibility to select either version at runtime with no code changes.
+
+Support
+
+The EventMachine development team has committed to support precisely the same APIs for all the
+various implementations of EM.
+
+This means that you can expect any EM program to behave identically, whether you use pure Ruby,
+the compiled C++ extension, or JRuby. Deviations from this behavior are to be considered bugs
+and should be reported as such.
+
+There is a small number of exceptions to this rule, which arise from underlying platform
+distinctions. Notably, EM#epoll is a silent no-op in the pure Ruby implementation.
+
+
+When Should You Use the Pure-Ruby Implementation of EM?
+
+
+Use the pure Ruby implementation of EM when you must support a platform for which no C++ compiler
+is available, or on which the standard EM C++ code can't be compiled.
+
+Keep in mind that you don't need a C++ compiler in order to deploy EM applications that rely on
+the compiled version, so long as appropriate C++ runtime libraries are available on the target platform.
+
+In extreme cases, you may find that you can develop software with the compiled EM version, but are
+not allowed to install required runtime libraries on the deployment system(s). This would be another
+case in which the pure Ruby implementation can be useful.
+
+In general you should avoid the pure Ruby version of EM when performance and scalability are important.
+EM in pure Ruby will necessarily run slower than the compiled version. Depending on your application
+this may or may not be a key issue.
+
+Also, since EPOLL is not supported in pure Ruby, your applications will be affected by Ruby's built-in
+limit of 1024 file and socket descriptors that may be open in a single process. For maximum scalability
+and performance, always use EPOLL if possible.
+

data/docs/RELEASE_NOTES

@@ -0,0 +1,94 @@
+RUBY/EventMachine RELEASE NOTES
+
+--------------------------------------------------
+Version: 0.9.0, released xxXXX07
+Added Erlang-like distributed-computing features
+
+--------------------------------------------------
+Version: 0.8.0, released 23Jun07
+Added an epoll implementation for Linux 2.6 kernels.
+Added evented #popen.
+
+--------------------------------------------------
+Version: 0.7.3, released 22May07
+Added a large variety of small features. See the ChangeLog.
+
+--------------------------------------------------
+Version: 0.7.1, released xxNov06
+Added protocol handlers for line-oriented protocols.
+Various bug fixes.
+
+--------------------------------------------------
+Version: 0.7.0, released 20Nov06
+Added a fix in em.cpp/ConnectToServer to fix a fatal exception that
+occurred in FreeBSD when connecting successfully to a remote server.
+
+--------------------------------------------------
+Version: 0.6.0, released xxJul06
+Added deferred operations, suggested by Don Stocks, amillionhitpoints@yahoo.com.
+
+--------------------------------------------------
+Version: 0.5.4, released xxJun06
+Added get_peername support for streams and datagrams.
+
+--------------------------------------------------
+Version: 0.5.3, released 17May06
+Fixed bugs in extconf.rb, thanks to Daniel Harple, dharple@generalconsumption.org.
+Added proper setup.rb and rake tasks, thanks to Austin Ziegler.
+Fixed a handful of reported problems with builds on various platforms.
+
+--------------------------------------------------
+Version: 0.5.2, released 05May06
+Made several nonvisible improvements to the Windows
+implementation.
+Added an exception-handling patch contributed by Jeff Rose, jeff@rosejn.net.
+Added a dir-config patch contributed anonymously.
+Supported builds on Solaris.
+
+--------------------------------------------------
+Version: 0.5.1, released 05May06
+Made it possible to pass a Class rather than a Module
+to a protocol handler.
+Added Windows port.
+
+--------------------------------------------------
+Version: 0.5.0, released 30Apr06
+Added a preliminary SSL/TLS extension. This will probably
+change over the next few releases.
+
+--------------------------------------------------
+Version: 0.4.5, released 29Apr06
+Changed ext files so the ruby.h is installed after unistd.h
+otherwise it doesn't compile on gcc 4.1
+
+--------------------------------------------------
+Version: 0.4.2, released 19Apr06
+Changed the Ruby-glue so the extension will play nicer
+in the sandbox with Ruby threads.
+Added an EventMachine::run_without_threads API to
+switch off the thread-awareness for better performance
+in programs that do not spin any Ruby threads.
+
+--------------------------------------------------
+Version: 0.4.1, released 15Apr06
+Reworked the shared-object interface to make it easier to
+use EventMachine from languages other than Ruby.
+
+--------------------------------------------------
+Version: 0.3.2, released 12Apr06
+Added support for a user-supplied block in EventMachine#connect.
+
+--------------------------------------------------
+Version: 0.3.1, released 11Apr06
+Fixed bug that prevented EventMachine from being run multiple
+times in a single process.
+
+--------------------------------------------------
+Version: 0.3.0, released 10Apr06
+Added method EventHandler::Connection::post_init
+
+--------------------------------------------------
+Version: 0.2.0, released 10Apr06
+Added method EventHandler::stop
+
+

data/docs/SMTP

@@ -0,0 +1,4 @@
+This note details the usage of EventMachine's built-in support for SMTP. EM
+supports both client and server connections, which will be described in
+separate sections.
+

data/docs/SPAWNED_PROCESSES

@@ -0,0 +1,148 @@
+EventMachine (EM) adds two different formalisms for lightweight concurrency
+to the Ruby programmer's toolbox: spawned processes and deferrables. This
+note will show you how to use spawned processes. For more information, see
+the separate document LIGHTWEIGHT_CONCURRENCY.
+
+
+=== What are Spawned Processes?
+
+Spawned Processes in EventMachine are inspired directly by the "processes"
+found in the Erlang programming language. EM deliberately borrows much (but
+not all) of Erlang's terminology. However, EM's spawned processes differ from
+Erlang's in ways that reflect not only Ruby style, but also the fact that
+Ruby is not a functional language like Erlang.
+
+Let's proceed with a complete, working code sample that we will analyze line
+by line. Here's an EM implementation of the "ping-pong" program that also
+appears in the Erlang tutorial:
+
+
+ require 'eventmachine'
+
+ EM.run {
+   pong = EM.spawn {|x, ping|
+     puts "Pong received #{x}"
+     ping.notify( x-1 )
+   }
+
+   ping = EM.spawn {|x|
+     if x > 0
+       puts "Pinging #{x}"
+       pong.notify x, self
+     else
+       EM.stop
+     end
+   }
+
+   ping.notify 3
+ }
+
+If you run this program, you'll see the following output:
+
+ Pinging 3
+ Pong received 3
+ Pinging 2
+ Pong received 2
+ Pinging 1
+ Pong received 1
+
+Let's take it step by step.
+
+EventMachine#spawn works very much like the built-in function spawn in
+Erlang. It returns a reference to a Ruby object of class
+EventMachine::SpawnedProcess, which is actually a schedulable entity. In
+Erlang, the value returned from spawn is called a "process identifier" or
+"pid." But we'll refer to the Ruby object returned from EM#spawn simply as a
+"spawned process."
+
+You pass a Ruby block with zero or more parameters to EventMachine#spawn.
+Like all Ruby blocks, this one is a closure, so it can refer to variables
+defined in the local context when you call EM#spawn.
+
+However, the code block passed to EM#spawn does NOT execute immediately by
+default. Rather, it will execute only when the Spawned Object is "notified."
+In Erlang, this process is called "message passing," and is done with the
+operator !, but in Ruby it's done simply by calling the #notify method of a
+spawned-process object. The parameters you pass to #notify must match those
+defined in the block that was originally passed to EM#spawn.
+
+When you call the #notify method of a spawned-process object, EM's reactor
+core will execute the code block originally passed to EM#spawn, at some point
+in the future. (#notify itself merely adds a notification to the object's
+message queue and ALWAYS returns immediately.)
+
+When a SpawnedProcess object executes a notification, it does so in the
+context of the SpawnedProcess object itself. The notified code block can see
+local context from the point at which EM#spawn was called. However, the value
+of "self" inside the notified code block is a reference to the SpawnedProcesss
+object itself.
+
+An EM spawned process is nothing more than a Ruby object with a message
+queue attached to it. You can have any number of spawned processes in your
+program without compromising scalability. You can notify a spawned process
+any number of times, and each notification will cause a "message" to be
+placed in the queue of the spawned process. Spawned processes with non-empty
+message queues are scheduled for execution automatically by the EM reactor.
+Spawned processes with no visible references are garbage-collected like any
+other Ruby object.
+
+Back to our code sample:
+
+   pong = EM.spawn {|x, ping|
+     puts "Pong received #{x}"
+     ping.notify( x-1 )
+   }
+
+This simply creates a spawned process and assigns it to the local variable
+pong. You can see that the spawned code block takes a numeric parameter and a
+reference to another spawned process. When pong is notified, it expects to
+receive arguments corresponding to these two parameters. It simply prints out
+the number it receives as the first argument. Then it notifies the spawned
+process referenced by the second argument, passing it the first argument
+minus 1.
+
+And then the block ends, which is crucial because otherwise nothing else
+can run. (Remember that in LC, scheduled entities run to completion and are
+never preempted.)
+
+On to the next bit of the code sample:
+
+   ping = EM.spawn {|x|
+     if x > 0
+       puts "Pinging #{x}"
+       pong.notify x, self
+     else
+       EM.stop
+     end
+   }
+
+Here, we're spawning a process that takes a single (numeric) parameter. If
+the parameter is greater than zero, the block writes it to the console. It
+then notifies the spawned process referenced by the pong local variable,
+passing as arguments its number argument, and a reference to itself. The
+latter reference, as you saw above, is used by pong to send a return
+notification.
+
+If the ping process receives a zero value, it will stop the reactor loop and
+end the program.
+
+Now we've created a pair of spawned processes, but nothing else has happened.
+If we stop now, the program will spin in the EM reactor loop, doing nothing
+at all. Our spawned processes will never be scheduled for execution.
+
+But look at the next line in the code sample:
+
+   ping.notify 3
+
+This line gets the ping-pong ball rolling. We call ping's #notify method,
+passing the argument 3. This causes a message to be sent to the ping spawned
+process. The message contains the single argument, and it causes the EM
+reactor to schedule the ping process. And this in turn results in the
+execution of the Ruby code block passed to EM#spawn when ping was created.
+Everything else proceeds as a result of the messages that are subsequently
+passed to each other by the spawned processes.
+
+[TODO, present the outbound network i/o use case, and clarify that spawned
+processes are interleaved with normal i/o operations and don't interfere
+with them at all. Also, blame Erlang for the confusing term "process"]
+