Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 15 Jan 2001 08:42:28 -0800 (PST)
From: dean gaudet <dgaudet-list-new-httpd@arctic.org>
To: <new-httpd@apache.org>
Subject: Re: File handle caching
In-Reply-To: <041401c07a88$672bd280$e4421b09@raleigh.ibm.com>
Message-ID: <Pine.LNX.4.30.0101150825080.30402-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 9 Jan 2001, Bill Stoddard wrote:

> When you cache a file handle on *nix, are file pointers maintained per
> process or per thread? I thought they were maintained per process
> which would mean that file handle caching is broken on *nix since
> there could easily be a race condition between calling apr_seek and
> sendfile.

per process.

actually it's more complex than that.  each process, and its threads,
share an array of "struct file *" (structure name varies by kernel), this
is indexed by fd.

struct file * contains the file seek offset, and a pointer to an inode.

the inode contains the rest of the info about the file.

when you fork() the new process gets a copy of the array of struct file *
...

which means a parent and its fork()ed children share the same seek offsets
into their open fds.

but on the specific problem of sharing an fd/offset amongst multiple
threads, there's pread(2)/pwrite(2) interfaces which allow
threaded/multi-process databases to use the same fd for all accesses.
and at least the linux sendfile(2) supports an offset for this reason
('cause i asked for it).

looking at the apr/network_io/unix/sendrecv.c code it looks like freebsd
and HPUX also have offset support in sendfile(), i'd assume they do the
right thing in-kernel to allow multiple threads to use the same fd.  i
would worry if we ever implement a sendfile for other unixes that we can't
use seek/read, we have to use pread() or otherwise lock the file between
seek/read (perhaps a sendfile lock in the apr_file_t).

-dean