Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

shells and bells



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).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org