Do not attempt to change the page size after a pager has entered the error state (Pager.errCode!=SQLITE_OK). This prevents an assertion failure in vacuum3.test. (CVS 5703)
check-in: aa5c9455 user: danielk1977 tags: trunk

**
** May you do good and not evil.
** May you find forgiveness for yourself and forgive others.
** May you share freely, never taking more than you give.
**
*************************************************************************
**
** $Id: test_async.c,v 1.46 2008/09/15 14:08:04 danielk1977 Exp $
**
** This file contains an example implementation of an asynchronous IO
** backend for SQLite.
**
** WHAT IS ASYNCHRONOUS I/O?
**
** With asynchronous I/O, write requests are handled by a separate thread
................................................................................
** to occur. The write seems to happen very quickly, though in reality
** it is happening at its usual slow pace in the background.
**
** Asynchronous I/O appears to give better responsiveness, but at a price.
** You lose the Durable property. With the default I/O backend of SQLite,
** once a write completes, you know that the information you wrote is
** safely on disk. With the asynchronous I/O, this is not the case. If
** your program crashes or if a power lose occurs after the database
** write but before the asynchronous write thread has completed, then the
** database change might never make it to disk and the next user of the
** database might not see your change.
**
** You lose Durability with asynchronous I/O, but you still retain the
** other parts of ACID: Atomic, Consistent, and Isolated. Many
** appliations get along fine without the Durablity.
................................................................................
**
** Basic rules:
**
** * Both read and write access to the global write-op queue must be
** protected by the async.queueMutex. As are the async.ioError and
** async.nFile variables.
**
** * The async.aLock hash-table and all AsyncLock and AsyncFileLock
** structures must be protected by the async.lockMutex mutex.
**
** * The file handles from the underlying system are assumed not to
** be thread safe.
**
** * See the last two paragraphs under "The Writer Thread" for
** an assumption to do with file-handle synchronization by the Os.
**
** Deadlock prevention:
**

**
** May you do good and not evil.
** May you find forgiveness for yourself and forgive others.
** May you share freely, never taking more than you give.
**
*************************************************************************
**
** $Id: test_async.c,v 1.47 2008/09/15 15:49:34 danielk1977 Exp $
**
** This file contains an example implementation of an asynchronous IO
** backend for SQLite.
**
** WHAT IS ASYNCHRONOUS I/O?
**
** With asynchronous I/O, write requests are handled by a separate thread
................................................................................
** to occur. The write seems to happen very quickly, though in reality
** it is happening at its usual slow pace in the background.
**
** Asynchronous I/O appears to give better responsiveness, but at a price.
** You lose the Durable property. With the default I/O backend of SQLite,
** once a write completes, you know that the information you wrote is
** safely on disk. With the asynchronous I/O, this is not the case. If
** your program crashes or if a power loss occurs after the database
** write but before the asynchronous write thread has completed, then the
** database change might never make it to disk and the next user of the
** database might not see your change.
**
** You lose Durability with asynchronous I/O, but you still retain the
** other parts of ACID: Atomic, Consistent, and Isolated. Many
** appliations get along fine without the Durablity.
................................................................................
**
** Basic rules:
**
** * Both read and write access to the global write-op queue must be
** protected by the async.queueMutex. As are the async.ioError and
** async.nFile variables.
**
** * The async.pLock list and all AsyncLock and AsyncFileLock
** structures must be protected by the async.lockMutex mutex.
**
** * The file handles from the underlying system are not assumed to
** be thread safe.
**
** * See the last two paragraphs under "The Writer Thread" for
** an assumption to do with file-handle synchronization by the Os.
**
** Deadlock prevention:
**

This page was generated in about
0.006s by
Fossil 2.8 [246f249e5a] 2019-01-21 20:07:41