eventmachine 0.12.10-x86-mswin32-60 → 1.0.0.beta.2-x86-mswin32-60

data/docs/INSTALL

@@ -1,13 +1,13 @@
-If you have obtained an EventMachine source-tarball (.tar.gz):
-unzip and untar the tarball, and enter the directory that is
-created. In that directory, say:
-ruby setup.rb
-(You may need to be root to execute this command.)
-
-To create documentation for EventMachine, simply type:
-rake rdoc
-in the distro directory. Rdocs will be created in subdirectory rdoc.
-
-If you have obtained a gem version of EventMachine, install it in the
-usual way (gem install eventmachine). You may need superuser privileges
-to execute this command.
+If you have obtained an EventMachine source-tarball (.tar.gz):
+unzip and untar the tarball, and enter the directory that is
+created. In that directory, say:
+ruby setup.rb
+(You may need to be root to execute this command.)
+
+To create documentation for EventMachine, simply type:
+rake rdoc
+in the distro directory. Rdocs will be created in subdirectory rdoc.
+
+If you have obtained a gem version of EventMachine, install it in the
+usual way (gem install eventmachine). You may need superuser privileges
+to execute this command.

data/docs/KEYBOARD

@@ -1,38 +1,42 @@
-EventMachine (EM) can respond to keyboard events. This gives your event-driven programs the ability to respond to input from local users.
-
-Programming EM to handle keyboard input in Ruby is simplicity itself. Just use EventMachine#open_keyboard, and supply the name of a Ruby module or class that will receive the input:
-
- require 'rubygems'
- require 'eventmachine'
- 
- module MyKeyboardHandler
- 	def receive_data keystrokes
- 		puts "I received the following data from the keyboard: #{keystrokes}"
- 	end
- end
- 
- EM.run {
- 	EM.open_keyboard(MyKeyboardHandler)
- }
-
-
-If you want EM to send line-buffered keyboard input to your program, just include the LineText2 protocol module in your handler class or module:
-
-
-
- require 'rubygems'
- require 'eventmachine'
- 
- module MyKeyboardHandler
- 	include EM::Protocols::LineText2
- 	def receive_line data
- 		puts "I received the following line from the keyboard: #{data}"
- 	end
- end
- 
- EM.run {
- 	EM.open_keyboard(MyKeyboardHandler)
- }
-
-As we said, simplicity itself. You can call EventMachine#open_keyboard at any time while the EM reactor loop is running. In other words, the method invocation may appear anywhere in an EventMachine#run block, or in any code invoked in the #run block.
-
+EventMachine (EM) can respond to keyboard events. This gives your event-driven
+programs the ability to respond to input from local users.
+
+Programming EM to handle keyboard input in Ruby is simplicity itself. Just use
+EventMachine#open_keyboard, and supply the name of a Ruby module or class that
+will receive the input:
+
+ require 'rubygems'
+ require 'eventmachine'
+
+ module MyKeyboardHandler
+ 	def receive_data keystrokes
+ 		puts "I received the following data from the keyboard: #{keystrokes}"
+ 	end
+ end
+
+ EM.run {
+ 	EM.open_keyboard(MyKeyboardHandler)
+ }
+
+If you want EM to send line-buffered keyboard input to your program, just
+include the LineText2 protocol module in your handler class or module:
+
+ require 'rubygems'
+ require 'eventmachine'
+
+ module MyKeyboardHandler
+ 	include EM::Protocols::LineText2
+ 	def receive_line data
+ 		puts "I received the following line from the keyboard: #{data}"
+ 	end
+ end
+
+ EM.run {
+ 	EM.open_keyboard(MyKeyboardHandler)
+ }
+
+As we said, simplicity itself. You can call EventMachine#open_keyboard at any
+time while the EM reactor loop is running. In other words, the method
+invocation may appear anywhere in an EventMachine#run block, or in any code
+invoked in the #run block.
+

data/docs/LEGAL

@@ -1,25 +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).
-
+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

@@ -1,70 +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 scalabiity 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.
-
+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

@@ -1,75 +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.
-
+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.
+