shells and bells

[ddm at mclinux.com (Derek Martin)]

On Wed, 3 May 2000, Derek Martin wrote:

> As I understand the problem (and I'll admit up front that my understanding
> may be flawed), this is due to the fact that a database write, while
> "atomic" from the database's perspective, is not an atomic operation from
> the kernel's perspective, unless the whole operation can be done with
> exactly one system call (system calls are guaranteed to be atomic, IIRC).
> Otherwise, the dbms may finish its time slice while a record update is in
> progress, at which time the back-up program may read the database's files,
> yeilding spaghetti data on your backup tape.

Actually, it's even worse than this.  A few minutes with W. Richard
Stevens' Unix Network Programming reveals that several "slow" system
calls, including write, read, ioctl, select, et. al. CAN be interrupted
and are not atomic.  This typically happens when the process receives some
signal, at which point the system recall returns with the error EINTR.
A context switch can occur here.

Stevens will be missed... 

-- 
Derek Martin
System Administrator
Mission Critical Linux
martin at MissionCriticalLinux.com 

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).