httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: File handle caching
Date Mon, 15 Jan 2001 16:42:28 GMT
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).


View raw message