Commit 5953d459 authored by Dan Egnor's avatar Dan Egnor
Browse files

Fix ``

parent 064a059c
......@@ -45,7 +45,7 @@ caller, which usually shuts down the system.
<h4>The system event source.</h4>
Liboop comes with a single ``reference'' implementation of an event source.
Liboop comes with a single "reference" implementation of an event source.
This event source uses select() to dispatch events. Most programs built
around liboop will probably use the standard system event source; legacy
programs with their own event loop, or programs with specialized needs may
......
......@@ -8,8 +8,8 @@
<p>
Liboop is a low-level event loop management library for POSIX-based operating
systems. It supports the development of modular, multiplexed applications
which may respond to events from several sources. It replaces the ``select()
loop'' and allows the registration of event handlers for file and network I/O,
which may respond to events from several sources. It replaces the "select()
loop" and allows the registration of event handlers for file and network I/O,
timers and signals. Since processes use these mechanisms for almost all
external communication, liboop can be used as the basis for almost any
application.
......
......@@ -29,7 +29,7 @@ events.<p>
When one of the callbacks returns some other value, oop_sys_run returns this
value. You can use this technique to allow callbacks to return data to the
``owner'' of the event loop (the caller of oop_sys_run). You may then decide
"owner" of the event loop (the caller of oop_sys_run). You may then decide
whether to restart the event loop (by calling oop_sys_run again) or not.<p>
If an error occurs waiting for events, oop_sys_run returns OOP_ERROR.
......
......@@ -20,12 +20,12 @@ might want to maintain several active user interfaces at once.
Furthermore, each of these interfaces may be quite complex, sufficiently so to
merit shared code modules which specialize in managing the interface.
Widget sets deal with the details of the X protocol and graphical user
interface management; ``curses'' deals with the arcana of character-based
interface management; "curses" deals with the arcana of character-based
terminals; WWW libraries offer high-level access to whole families of Internet
transfer protocols; standard I/O and database routines manage filesystem data.
<p>
However, the existing techniques available for multiplexing interface code are
very poor. Most of these libraries work in ``blocking'' fashion; once
very poor. Most of these libraries work in "blocking" fashion; once
instructed to complete a task (such as downloading a file, or presenting a
dialog to the user), they do not return until the task is complete (or failed),
even though this may mean waiting an arbitrary amount of time for some external
......@@ -35,7 +35,7 @@ other components.
<p>
Developers are thus left with several unpalatable choices:
<ol>
<li>Accept ``blocking'' operation. User interfaces stop functioning while the
<li>Accept "blocking" operation. User interfaces stop functioning while the
application waits for the network; one network client's access is stalled
while another client performs a transaction. As more data moves from local
storage (where access is fast enough that blocking is acceptable) to
......@@ -45,23 +45,23 @@ some problems, developers who choose this route must struggle with relatively
immature and unportable threading models, and deal with the many libraries
which are not thread-safe; furthermore, threaded programming requires
thought-intensive and error-prone synchronization.
<li>Use multiple processes (``forking'') for concurrency. This can also work,
<li>Use multiple processes ("forking") for concurrency. This can also work,
but requires all communication between modules to use some form of
inter-process communication, which increases complexity and decreases
performance. Forking itself is a slow operation, leading to complex
``pre-forking'' schemes for better performance. Worst of all, each process
"pre-forking" schemes for better performance. Worst of all, each process
must somehow multiplex IPC from other processes with whatever I/O task it had
to accomplish in the first place; this brings back the very problem forking
was designed to address.
<li>Attempt to multiplex each library's I/O operations directly in a master
``select loop''. This requires the developer to understand intimately the
"select loop". This requires the developer to understand intimately the
exact details of each library's I/O interactions, thus breaking modularity,
fostering unhealthy dependency and leading to a single central snarl through
which all I/O must pass.
</ol>
The paucity of options is reflected in the quality of applications. How many
programs hang unpleasantly while performing simple network operations like
hostname resolution? How many user interfaces are unnecessarily ``modal''?
hostname resolution? How many user interfaces are unnecessarily "modal"?
How many simple servers fork for no good reason? How many network applications
simply don't exist because it's so difficult to write them?
......@@ -73,7 +73,7 @@ source</em>. These callbacks may be tied to file-descriptor activity, the
system time, or process signals. Liboop is responsible for invoking these
callbacks as appropriate.
<p>
With this system, each module ``owns'' its own I/O; it can perform arbitrarily
With this system, each module "owns" its own I/O; it can perform arbitrarily
complex operations without blocking anything else in the program. But since
callbacks are executed purely sequentially, there is no complex concurrent code
to manage. From the application developer's point of view, working with liboop
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment