sensu-em 2.4.0-x86-mingw32

data/docs/old/EPOLL

@@ -0,0 +1,141 @@
+EventMachine now supports epoll, bringing large increases in performance and scalability to Ruby programs.
+
+Epoll(7) is a alternative mechanism for multiplexed I/O that is available in Linux 2.6 kernels.
+It features significantly greater performance than the standard select(2) mechanism, when used in
+applications that require very large numbers of open I/O descriptors.
+
+EventMachine has always used select(2) because its behavior is well standardized and broadly supported.
+But select becomes unreasonably slow when a program has a
+very large number of file descriptors or sockets. Ruby's version of select hardcodes a limit
+of 1024 descriptors per process, but heavily loaded processes will start to show performance
+degradation even after only a few hundred descriptors are in use.
+
+Epoll is an extended version of the poll(2) call, and it solves the problems with select. Programs
+based on epoll can easily scale past Ruby's 1024-descriptor limit, potentially to tens of thousands
+of connectors, with no significant impact on performance.
+
+(Another alternative which is very similar to epoll in principle is kqueue, supplied on BSD and its
+variants.)
+
+
+
+This note shows you how to use epoll in your programs.
+
+=== Compiling EventMachine to use epoll.
+
+You don't have to do anything to get epoll support in EventMachine.
+When you compile EventMachine on a platform that supports epoll, EM will
+automatically generate a Makefile that includes epoll. (At this writing, this will only work
+on Linux 2.6 kernels.) If you compile EM on a platform without epoll, then epoll support will
+be omitted from the Makefile, and EM will work just as it always has.
+
+=== Using epoll in your programs.
+
+First, you need to tell EventMachine to use epoll instead of select (but see below, as this requirement
+will be removed in a future EventMachine version). Second, you need to prepare your program to use
+more than 1024 descriptors, an operation that generally requires superuser privileges. Third, you will probably
+want your process to drop the superuser privileges after you increase your process's descriptor limit.
+
+=== Using EventMachine#epoll
+
+Call the method EventMachine#epoll anytime before you call EventMachine#run, and your program will
+automatically use epoll, if available. It's safe to call EventMachine#epoll on any platform because
+it compiles to a no-op on platforms that don't support epoll.
+
+  require 'rubygems'
+  require 'eventmachine'
+
+  EM.epoll
+  EM.run {
+    ...
+  }
+
+
+EventMachine#epoll was included in this initial release only to avoid changing the behavior of existing
+programs. However, it's expected that a future release of EM will convert EventMachine#epoll to a no-op,
+and run epoll by default on platforms that support it.
+
+=== Using EventMachine#set_descriptor_table_size
+
+In Linux (as in every Unix-like platform), every process has a internal table that determines the maximum
+number of file and socket descriptors you may have open at any given time. The size of this table is
+generally fixed at 1024, although it may be increased within certain system-defined hard and soft limits.
+
+If you want your EventMachine program to support more than 1024 total descriptors, you must use 
+EventMachine#set_descriptor_table_size, as follows:
+
+  require 'rubygems'
+  require 'eventmachine'
+
+  new_size = EM.set_descriptor_table_size( 60000 )
+  $>.puts "New descriptor-table size is #{new_size}"
+
+  EM.run {
+    ...
+  }
+
+If successful, this example will increase the maximum number of descriptors that epoll can use to 60,000.
+Call EventMachine#set_descriptor_table_size without an argument at any time to find out the current
+size of the descriptor table.
+
+Using EventMachine#set_descriptor_table_size ONLY affects the number of descriptors that can be used
+by epoll. It has no useful effect on platforms that don't support epoll, and it does NOT increase the
+number of descriptors that Ruby's own I/O functions can use.
+
+#set_descriptor_table_size can fail if your process is not running as superuser, or if you try to set a
+table size that exceeds the hard limits imposed by your system. In the latter case, try a smaller number.
+
+
+=== Using EventMachine#set_effective_user
+
+In general, you must run your program with elevated or superuser privileges if you want to increase
+your descriptor-table size beyond 1024 descriptors. This is easy enough to verify. Try running the
+sample program given above, that increases the descriptor limit to 60,000. You will probably find that
+the table size will not be increased if you don't run your program as root or with elevated privileges.
+
+But of course network servers, especially long-running ones, should not run with elevated privileges.
+You will want to drop superuser privileges as soon as possible after initialization. To do this,
+use EventMachine#set_effective_user:
+
+  require 'rubygems'
+  require 'eventmachine'
+
+  # (Here, program is running as superuser)
+
+  EM.set_descriptor_table_size( 60000 )
+  EM.set_effective_user( "nobody" )
+  # (Here, program is running as nobody)
+
+  EM.run {
+    ...
+  }
+
+Of course, you will need to replace "nobody" in the example with the name of an unprivileged user
+that is valid on your system. What if you want to drop privileges after opening a server socket
+on a privileged (low-numbered) port? Easy, just call #set_effective_user after opening your sockets:
+
+  require 'rubygems'
+  require 'eventmachine'
+
+  # (Here, program is running as superuser)
+
+  EM.set_descriptor_table_size( 60000 )
+
+  EM.run {
+    EM.start_server( "0.0.0.0", 80, MyHttpServer )
+    EM.start_server( "0.0.0.0", 443, MyEncryptedHttpServer )
+
+    EM.set_effective_user( "nobody" )
+    # (Here, program is running as nobody)
+
+    ...
+  }
+
+
+Because EventMachine#set_effective_user is used to enforce security
+requirements, it has no nonfatal errors. If you try to set a nonexistent or invalid effective user,
+#set_effective_user will abort your program, rather than continue to run with elevated privileges.
+
+EventMachine#set_effective_user is a silent no-op on platforms that don't support it, such as Windows.
+
+

data/docs/old/INSTALL

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

data/docs/old/KEYBOARD

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

data/docs/old/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/old/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/old/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/old/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
+
+