httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Wan-Teh Chang)
Subject Re: rewritelog inefficiency
Date Tue, 28 Apr 1998 14:44:03 GMT

Dean Gaudet wrote:

> There's no pressing need to fd_lock()/fd_unlock() around the rewritelog
> write() call... unless for some reason the log entries are larger than
> 4k... typical value for PIPE_MAX -- the guaranteed atomic write size on
> pipes.
> Hmm.  I don't recall seeing a similar guarantee in NSPR... I'll make a
> note of that.

Hi, I am in the NSPR group.  You are right, NSPR does not guaranteethat
writes to a PRFileDesc are atomic.  So if you have several threads
writing to the the same PRFileDesc (as is the case in logging), it's safer
lock the fd when you write to ensure atomicity.

If the write system calls of the underlaying OS are atomic, and the
PRFileDesc in question is not layered (e.g., no buffering layer),
then very likely the NSPR writes to *normal files* are also atomic.
(NSPR turns on the O_NONBLOCK flag for sockets and pipes
on Unix, but does not do so for normal (disk) files.)
But I'll need to examine our source code carefully to be sure.


View raw message