spell-check.

01_intro.txt

@@ -25,7 +25,7 @@ include::examples_01/01_sync_webclient.c[]
 -------
 
 All of the network calls in the code above are _blocking_: the
-gethostbyname does not return until it has suceeded or failed in
+gethostbyname does not return until it has succeeded or failed in
 resolving www.google.com; the connect does not return until it has
 connected; the recv calls do not return until they have received data
 or a close; and the send call does not return until it has at least
@@ -82,7 +82,7 @@ you'd want to use a thread pool instead of creating new processes.
 But more fundamentally, threads won't scale as much as you'd like. If
 your program needs to handle thousands or tens of thousands of
 connections at a time, dealing with tens of thousands of threads will
-not be as efficient as trying to have have only a few threads per CPU.
+not be as efficient as trying to have only a few threads per CPU.
 
 But if threading isn't the answer to having multiple connections, what is?
 In the Unix paradigm, you make your sockets _nonblocking_. The Unix
@@ -102,7 +102,7 @@ might be naively written as:
 
 [code,C]
 ------
-/* This will work, but the performance will be unforgiveably bad. */
+/* This will work, but the performance will be unforgivably bad. */
 for (i=0; i < n_sockets; ++i)
  fcntl(fd[i], F_SETFL, O_NONBLOCK);
 

Ref0_meta.txt

@@ -23,7 +23,7 @@ Speed::
  overhead as it does so.
 
 Scalability::
- Libevent is designed to work well even with progams that need to
+ Libevent is designed to work well even with programs that need to
  have tens of thousands of active sockets.
 
 Convenience::
@@ -166,15 +166,15 @@ Some other notes on working with older versions:
 Individual sections below will discuss the obsolete APIs that you
 might encounter for specific areas of the codebase.
 
-Notes on vesion status
-^^^^^^^^^^^^^^^^^^^^^^
+Notes on version status
+^^^^^^^^^^^^^^^^^^^^^^^
 
 Versions of Libevent before 1.4.7 or so should be considered totally
 obsolete. Versions of Libevent before 1.3e or so should be considered
 hopelessly bug-ridden.
 
 (Also, please don't send the Libevent maintainers any new features for
 1.4.x or earlier---it's supposed to stay as a stable release. And
-if you encounter a bug in 1.3x or ealier, please make sure that it
+if you encounter a bug in 1.3x or earlier, please make sure that it
 still exists in the latest stable version before you report it:
 subsequent releases have happened for a reason.)

Ref1_libsetup.txt

@@ -203,9 +203,9 @@ functions to use. You need to do this before you call any Libevent
 function that allocates a structure that needs to be shared between
 threads.
 
-If you are using the pthreads library, or the native windows threading
-code, you're in luck. There are pre-defined functions that will set up
-the right FIXME
+If you are using the pthreads library, or the native Windows threading
+code, you're in luck. There are pre-defined functions that will set Libevent
+up to use the right pthreads or Windows functions for you.
 
 .Interface
 [code]
@@ -330,7 +330,7 @@ Thus, the released Libevent 2.0.1-alpha has the version number of [02 00
 int
 make_sandwich(void)
 {
- /* Let's suppose that Libevent 6.0.5 intruduces a make-me-a
+ /* Let's suppose that Libevent 6.0.5 introduces a make-me-a
  sandwich function. */
 #if LIBEVENT_VERSION_NUMBER >= 0x06000500
  evutil_make_me_a_sandwich();

Ref2_eventbase.txt

@@ -99,7 +99,8 @@ int event_config_set_flag(struct event_config *cfg,
 Calling event_config_avoid_method tells Libevent to avoid a specific
 available backend by name. Calling event_config_require_feature() tells
 Libevent not to use any backend that cannot supply all of a set of features.
-Calling event_config_set_flag() AKDJASD FIXME
+
+// Calling event_config_set_flag() XXXXX FIXME
 
 The recognized feature values for event_config_require_features are:
 
@@ -345,7 +346,7 @@ struct event_base *event_init(void);
 
 This function worked like event_base_new(), and set the current base
 to the allocated base. There was no other way to change the
-curent base.
+current base.
 
 
 Some of the event_base functions in this section had variants that

Ref4_event.txt

@@ -223,7 +223,7 @@ Setting up events without heap-allocation
 For performance and other reasons, some people like to allocate events
 as a part of a larger structure. For each use of the event, this
 saves them:
- - The memory allocater overhead for allocating a small object on
+ - The memory allocator overhead for allocating a small object on
  the heap.
  - The time overhead for dereferencing the pointer to the
  struct event.
@@ -480,7 +480,7 @@ associated with an event.
 Since versions of Libevent before 2.0 did not have
 locking support, it wasn't safe to call any of the functions that
 change an event's state with respect to a base from outside the thread
-running the base. Thse include event_add(), event_del(),
+running the base. These include event_add(), event_del(),
 event_active(), and event_base_once().
 
 There was also an event_once() function that played the role of

Ref5_evutil.txt

@@ -22,7 +22,7 @@ system hands them out in numeric order. Using the Windows socket API,
 however, a socket is of type SOCKET, which is really a pointer-like OS
 handle, and the order you receive them is undefined. We define the
 evutil_socket_t type to be an integer that can hold the output of
-socket() or accept() wihtout risking pointer truncation on Windows.
+socket() or accept() without risking pointer truncation on Windows.
 
 .Definition
 [code]
@@ -40,7 +40,7 @@ Standard integer types
 ^^^^^^^^^^^^^^^^^^^^^^
 
 Often you will find yourself on a C system that missed out on the 21st
-century and therefore does does not implement the standard C99
+century and therefore does not implement the standard C99
 stdint.h header. For this situation, Libevent defines its own
 versions of the bit-width-specific integers from stdint.h:
 

Ref6_bufferevent.txt

@@ -11,10 +11,10 @@ write data, for example, the usual pattern runs something like:
 
 - Decide that we want to write some data to a connection; put that
  data in a buffer.
-- Wait for the connection to become writeable
+- Wait for the connection to become writable
 - Write as much of the data as we can
 - Remember how much we wrote, and if we still have more data to write,
- wait for the connection to become writeable again.
+ wait for the connection to become writable again.
 
 This buffered IO pattern is common enough that Libevent provides a
 generic mechanism for it. A "bufferevent" consists of an
@@ -136,7 +136,7 @@ the corresponding condition happens. (This is true of evbuffer
 callbacks too; we'll get to those later.) This immediate invocation
 can make trouble when dependencies get complex. For example, suppose
 that there is a callback that moves data into evbuffer A when it grows
-empty, and another callback that processs data out of evbuffer A when
+empty, and another callback that process data out of evbuffer A when
 it grows full. Since these calls are all happening on the stack, you
 might risk a stack overflow if the dependency grows nasty enough.
 
@@ -199,7 +199,7 @@ you want to set the file descriptor later.
 
 This function returns a bufferevent on success, and NULL on failure.
 
-The buffervent_socket_new() function was introduced in Libevent 2.0.1-alpha.
+The bufferevent_socket_new() function was introduced in Libevent 2.0.1-alpha.
 
 Launching connections on socket-based bufferevents
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -465,7 +465,7 @@ If writing on the bufferevent was stalled because of too little data
 the output buffer (or removing data from the input buffer) will
 automatically restart it.
 
-These fuctions were introduced in Libevent 2.0.1-alpha.
+These functions were introduced in Libevent 2.0.1-alpha.
 
 .Interface
 [code]
@@ -495,15 +495,15 @@ int bufferevent_read_buffer(struct bufferevent *bufev,
 These functions remove data from a bufferevent's input buffer. The
 bufferevent_read() function removes up to 'size' bytes from the input
 buffer, storing them into the memory at 'data'. It returns the number
-of bytes actually removed. The buferevent_read_buffer() function
+of bytes actually removed. The bufferevent_read_buffer() function
 drains the entire contents of the input buffer and places them into
 'buf'; it returns 0 on success and -1 on failure.
 
 Note that with bufferevent_read(), the memory chunk at 'data' must
 actually have enough space to hold 'size' bytes of data.
 
 The bufferevent_read() function has existed since before Libevent 1.0;
-bufferevent_read_buffer() was introducd in Libevent 2.0.1-alpha.
+bufferevent_read_buffer() was introduced in Libevent 2.0.1-alpha.
 
 .Example
 [code]
@@ -551,7 +551,7 @@ struct count {
 void
 write_callback_fibonacci(struct bufferevent *bev, void *ctx)
 {
- /* Here's a callback that adds some fibanocci numbers to the
+ /* Here's a callback that adds some Fibonacci numbers to the
  output buffer of bev. It stops once we have added 1k of
  data; once this data is drained, we'll add more. */
  struct count *c = ctx;

Ref7_evbuffer.txt

@@ -56,7 +56,7 @@ make a set of operations atomic. If locking has not been enabled on
 the evbuffer, these functions do nothing.
 
 (Note that you do not need to call evbuffer_lock() and
-evbuffer_unlock() around _invididual_ operations: if locking is
+evbuffer_unlock() around _individual_ operations: if locking is
 enabled on the evbuffer, individual operations are already atomic.
 You only need to lock the evbuffer manually when you have more than
 one operation that need to execute without another thread butting in.)
@@ -184,7 +184,7 @@ shared with a bufferevent. They were new in Libevent 2.0.1-alpha.
 Rearranging the internal layout of an evbuffer
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Sometimes you want to peek at the the first N bytes of data in the
+Sometimes you want to peek at the first N bytes of data in the
 front of an evbuffer, and see it as a contiguous array of bytes. To
 do this, you must first ensure that the front of the buffer really _is_
 contiguous.
@@ -482,7 +482,7 @@ for (i=0; i<n; ++i) {
  size_t len = v[i].iov_len;
  if (written + len > 4096)
  len = 4096 - written;
- r = write(1 /* stdiout */, v[i].iov_base, len);
+ r = write(1 /* stdout */, v[i].iov_base, len);
  if (r<=0)
  break;
  /* We keep track of the bytes written separately; if we don't,
@@ -690,7 +690,7 @@ On Unix, these functions should work on any file descriptor that
 supports read and write. On Windows, only sockets are supported.
 
 Note that when you are using bufferevents, you do not need to call
-these IO functions; the buferevents code does it for you.
+these IO functions; the bufferevents code does it for you.
 
 The evbuffer_write_atmost() function was introduced in Libevent 2.0.1-alpha.
 
@@ -734,7 +734,7 @@ The evbuffer_add_cb() function adds a callback to an evbuffer, and
 returns an opaque pointer that can later be used to refer to this
 particular callback instance. The 'cb' argument is the function that
 will be invoked, and the 'cbarg' is the user-supplied pointer to pass
-to the funtion.
+to the function.
 
 You can have multiple callbacks set on a single evbuffer. Adding a
 new callback does not remove old callbacks.
@@ -801,7 +801,7 @@ you added it, or by the callback and pointer you used. The
 evbuffer_remove_cb() functions return 0 on success and -1 on failure.
 
 The evbuffer_cb_set_flags() function and the evbuffer_cb_clear_flags()
-fuction make a given flag be set or cleared on a given callback
+function make a given flag be set or cleared on a given callback
 respectively. Right now, only one user-visible flag is supported:
 'EVBUFFER_CB_ENABLED'. The flag is set by default. When it is
 cleared, modifications to the evbuffer do not cause this callback to
@@ -994,7 +994,7 @@ unsigned char *evbuffer_find(struct evbuffer *buffer,
 --------
 
 The evbuffer_readline() function worked like the current
-evbufer_readln(buffer, NULL, EVBUFFER_EOL_ANY).
+evbuffer_readln(buffer, NULL, EVBUFFER_EOL_ANY).
 
 The evbuffer_find() function would search for the first occurrence of
 a string in a buffer, and return a pointer to it. Unlike