[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Single-threading servers and select()
- From: David Given <dg@...>
- Date: Sun, 23 Jan 2005 16:24:23 +0000
Adam D. Moss wrote:
David Given wrote:
> There's no reason why you can't have a persistant
pointer to a file; dereference the pointer and the appropriate file is
opened and a block read. This would trivialise the bulk of most
program's file I/O; MULTICS did it years ago; but you can't do it on a
Unix because the underlying design doesn't let you do that sort of
That sounds a lot like mmap(). Isn't it?
Yes, but you have to manually open the file, and because you don't know where
files get mapped, pointers can't be persistant. You have to store things as,
say, an offset from the start of the file.
Imagine a modern, 64-bit system. All pointers are 64 bits wide. Let's divide
this into two 32-bit values. If we treat the top half as being the inode
number of a file on disk, and the bottom half as being the offset from the
start of the file, then any pointer can address any file on disk *regardless
what process is using the pointer*.
In fact, that's not how you'd do it, and you'd divide up the address space
rather differently, but this kind of thing would let you, say, pass in a
filename to malloc() to tell it where you want the data to come from.
The problem with this is that to do it properly, you need an OS with a rather
different concept of what files are to how Unix does things.
[insert interesting .sig here]