From 5953d459664fe2e20796130a48dd33ec470fa97f Mon Sep 17 00:00:00 2001
From: Dan Egnor <egnor@ofb.net>
Date: Mon, 21 May 2001 21:03:23 +0000
Subject: [PATCH] Fix ``
---
how.html | 2 +-
index.html | 4 ++--
oop_sys_run.html | 2 +-
why.html | 16 ++++++++--------
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/how.html b/how.html
index 82f4bd3..f67edad 100644
--- a/how.html
+++ b/how.html
@@ -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
diff --git a/index.html b/index.html
index 017a7d9..822e9d1 100644
--- a/index.html
+++ b/index.html
@@ -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.
diff --git a/oop_sys_run.html b/oop_sys_run.html
index a9beb59..b2a986d 100644
--- a/oop_sys_run.html
+++ b/oop_sys_run.html
@@ -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.
diff --git a/why.html b/why.html
index 0a5dca4..944745f 100644
--- a/why.html
+++ b/why.html
@@ -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
--
GitLab