sysreq.html

sqlite3源码,适合作为嵌入式（embedded）

S20300</b></dt>
<dd><p>
The SQLite library shall provide interfaces that permit the application
to create new text collating sequences.
</p>
<p>By default, SQLite only understands ASCII text.  The tables needed
  to do proper comparisons and case folding
  of full unicode text are huge - much larger
  than the SQLite library itself.  And, any application that is dealing
  with unicode already probably already has those tables built in.  For
  SQLite to include unicode comparison tables would be redundant and wasteful.
  As a compromise, SQLite allows the application to specify alternative
  collating sequences for things such as unicode text,
  so that for applications that need such comparison sequences can have
  them easily while other applications that are content with ASCII are
  not burdened with unnecessary tables.
</p></dd>

<dt><b><a name="S20400"></a>
S20400</b></dt>
<dd><p>
The SQLite library shall provide interfaces that permit the application
to create new classes of virtual SQL tables.
</p>
<p>A virtual table is an SQL object that appears to be an ordinary
  SQL table for the purposes of INSERT, UPDATE, DELETE, and SELECT statements.
  But instead of being backed by persistent storage, the virtual table is
  an object that responds programmatically to INSERT, UPDATE, DELETE, and
  SELECT requests.  Virtual tables have been used to implement full-text
  search and R-Tree indices, among other things.
</p></dd>

<dt><b><a name="S20500"></a>
S20500</b></dt>
<dd><p>
The SQLite library shall provide interfaces that permit the application
to load extensions at run-time using shared libraries.
</p>
<p>Some applications choose to package extensions in separate
  shared library files and load those extensions at run-time on
  an as-needed basis.  Depending on the nature of the application,
  this can be an aid to configuration management, since it allows
  the extension to be updated without having to replace the core
  application.
</p></dd>

<dt><b><a name="S20600"></a>
S20600</b></dt>
<dd><p>
The SQLite library shall provide interfaces that permit the application
to dynamically query and modify size limits.
</p>
<p>SQLite has finite limits.  For example, there is a maximum size BLOB
  or CLOB that SQLite will store, a maximum size to a database file,
  a maximum number of columns in a table or query, and a maximum depth
  of an expression parse tree.  All of these have default values that
  are sufficiently large that a typical application is very unlikely to 
  ever reach the limits.  But some applications (for example, applications
  that process content from untrusted and possibly hostile sources)
  might want to define much lower limits on some database connections for
  the purpose of preventing denial-of-service attacks.  Or, an application
  might want to select much lower limits in order to prevent over-utilization
  of limited resources on an embedded device.  Whatever the rationale, SQLite
  permits limits to be queried and set at run-time.
</p></dd>

<dt><b><a name="S30000"></a>
S30000</b></dt>
<dd><p>
The SQLite library shall be safe for use in long-running,
low-resource, high-reliability applications.
</p>
<p>SQLite is designed to work well within embedded devices with 
  very limited resources.  To this end, it expects to confront situations
  where memory is unavailable and where I/O operations fail and it is designed
  to handle such situations with ease and grace.  SQLite also avoids aggravating
  low-resource situations by correctly freeing rather than leaking 
  resources it uses itself.
</p></dd>

<dt><b><a name="S30100"></a>
S30100</b></dt>
<dd><p>
The SQLite library shall release all system resources it holds
when it is properly shutdown.
</p>
<p>A "Proper shutdown" means that all resources that the application
  has allocated from SQLite have been released by the application.
  The leak-free operation guarantee of SQLite applies even if there
  have been memory allocation errors or I/O errors during operation.
</p></dd>

<dt><b><a name="S30200"></a>
S30200</b></dt>
<dd><p>
The SQLite library shall be configurable so that it is guaranteed
to never fail a memory allocation as long as the application does
not request resources in excess of reasonable and published limits.
</p>
<p>Safety-critical systems typically disallow the use of malloc() and
  free() because one never knows when they might fail due to memory
  fragmentation.  However, SQLite makes extensive use of dynamic objects
  and so it must be able to allocate and deallocate memory
  to hold those objects.</p>

  <p>In order to be acceptable for use in safety critical systems,
  SQLite can be configured to use its own internal memory allocator
  which, subject to proper usage by the application, guarantees that
  memory allocation will never fail either due to memory fragmentation
  or any other cause.  The proof of correctness is due to J. M. Robson:
  "Bounds for Some Functions Concerning Dynamic Storage Allocations",
  Journal of the ACM, Volume 21, Number 3, July 1974.</p>

  <p>The internal memory allocator is seeded with a large contiguous
  block of memory at application start.  SQLite makes all of its
  internal memory allocations from this initial seed.  
  The Robson proof depends on SQLite being coupled to a well-behaved
  application.  The application must not try to use more than a
  precomputed fraction of the available memory - that fraction depending
  on the size ratio between the largest and smallest memory allocations.
  Additional details are provided elsewhere.
</p></dd>

<dt><b><a name="S30210"></a>
S30210</b></dt>
<dd><p>
The SQLite library shall be provide instrumentation that can alert
the application when its resource usages nears or exceeds the limits
of the memory breakdown guarantee.
</p>
<p>To help insure that an
  application never fails a memory allocation call, SQLite provides
  interfaces that can inform the application if its memory usage
  is growing close to or has exceeded the critical Robson limits.  
  In practice, the memory used by an application can exceed the 
  limits of the Robson proof by a wide margin with no harmful effect.  
  There is plenty of safety margin.  But the Robson proof does break 
  down once the limits are exceeded  
  and the guarantee that no memory allocation will fail is lost.  Hence
  it is important to be able to track how close an application has come
  to reaching critical limits.
</p></dd>

<dt><b><a name="S30220"></a>
S30220</b></dt>
<dd><p>
The SQLite library shall be provide facilities to automatically
recycle memory when usage nears preset limits.
</p>
<p>When SQLite comes under memory pressure, it can be configured to
  recycle memory from one use to another, thus helping to reduce the
  pressure.  "Memory pressure" means that memory available for 
  allocation is becoming less plentiful.  In a safety-critical application,
  memory pressure might mean that the amount of allocated memory is
  getting close to the point where the Robson proof
  breaks down.  On a workstation, memory pressure might mean that
  available virtual memory is running low.
</p></dd>

<dt><b><a name="S30230"></a>
S30230</b></dt>
<dd><p>
The SQLite library shall be permit BLOB and CLOB objects to be
read and written incrementally using small memory buffers.
</p>
<p>SQLite provides the ability to read and write megabyte
  or gigabyte blobs and text strings without having to allocate
  enough memory to hold the entire blob and string in memory all
  at once.  This enables SQLite to read and write BLOBs that
  are actually larger than the available memory on the device.
  It also helps reduce the size of the maximum memory allocation
  which helps keep memory usage below Robson limits and thus helps
  to guarantee failure-free memory allocation.
</p></dd>

<dt><b><a name="S30300"></a>
S30300</b></dt>
<dd><p>
When a memory allocation fails, SQLite shall either silently make
due without the requested memory or else it shall report the error
back to the application.
</p>
<p>Memory allocation problems do not cause SQLite to fail
  catastrophically.
  SQLite recognizes all memory allocation failures and either works 
  around them, or
  cleanly aborts what it is doing and returns to the application
  with an error that indicates insufficient memory was available.
  Assuming new memory becomes available, SQLite is able to continue 
  operating normally after a memory allocation failure.
</p></dd>

<dt><b><a name="S30400"></a>
S30400</b></dt>
<dd><p>
When a I/O operation fails, SQLite shall either silently
recover or else it shall report the error
back to the application.
</p>
<p>SQLite responses sanely to disk I/O errors.  If it is unable
  to work around the problem, SQLite might have to report the error
  back up to the application.  In either case, SQLite is able to
  continue functioning, assuming of course that the I/O error was
  transient.
</p></dd>

<dt><b><a name="S30500"></a>
S30500</b></dt>
<dd><p>
SQLite shall provide the capability to monitor
the progress and interrupt the evaluation of a long-running query.
</p>
<p>SQLite is able to cleanly abort an operation in progress and
  afterwards continue functioning normally without any memory or
  other resource leaks.  An example of where this functionality is
  used occurs in the command-line interface (CLI) program for SQLite.
  If the user enters a query that has millions of result rows, those
  rows begin pouring out onto the screen.  The operator can then
  hit the interrupt key sequence (which varies from one operating
  system to another but it often Control-C) which causes the query
  to be aborted.
</p></dd>

<dt><b><a name="S30600"></a>
S30600</b></dt>
<dd><p>
All unused portions of a well-formed SQLite database file shall
be available for reuse.
</p>
<p>When information is deleted from an SQLite database, the default
  action is for SQLite to mark the space as unused and then to reuse
  the space at the next opportune INSERT.  On devices where persistent 
  storage is scarce, however, it is sometime desirable to return the
  unused space back to the operating system.  SQLite supports this.
</p></dd>

<dt><b><a name="S30700"></a>
S30700</b></dt>
<dd><p>
SQLite shall provide the capability to incrementally decrease the
size of the persistent storage file as information is removed from
the database.
</p></dd>

<dt><b><a name="S30800"></a>
S30800</b></dt>
<dd><p>
SQLite shall provide the interfaces that support testing and
validation of the library code in an as-delivered configuration.
</p>
<p>In consumer-grade software, it is often acceptable to run tests
  on an instrumented version of the code.  But for high-reliability
  systems, it is better to test the code exactly as it is deployed.
  The saying at NASA is "test what you fly and fly what you test."
  In support of this goal, SQLite includes interfaces whose only purpose
  is to observe internal state and to place SQLite into internal states
  for the testing.
</p></dd>

<dt><b><a name="S30900"></a>
S30900</b></dt>
<dd><p>
SQLite shall provide the ability for separate database connections
within the same process to share resources.
</p>
<p>On resource-constrained devices, it is desirable to get double-duty
  out of resources where possible.
</p></dd>

<dt><b><a name="S40000"></a>
S40000</b></dt>
<dd><p>
The SQLite library shall be safe for use in applications that
make concurrent access to the underlying database from different
threads and/or processes.
</p>
<p>In nearly all modern digital systems, there are many things happening
  at once.  And many of those things involve SQLite.
</p></dd>

<dt><b><a name="S40100"></a>
S40100</b></dt>
<dd><p>
The SQLite library shall be configurable to operate correctly in
a multi-threaded application.
</p>