Re: Single-threading servers and select()

[David Given <dg@...>]

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 
> > thing. Sigh.
>
> 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]