File descriptors as register windows?

[Jezze]

I just thought of something today and it is probably stupid but I'm just gonna explain it so you can contemplate it for five minutes before you discard it as gibberish. I honestly haven't given it a lot of thought myself.

I just thought, what would happen if you handle file descriptors the same way as registers are handled when using register windows? So let's say a task has 8 file descriptors 0 ... 7 it can use. Descriptor 0 would be the standard in and descriptor 7 would be stdout. Then when you fork and execute a new program the "file descriptor window" would be moved forward and stdin for the new task would now be the old stdout. The descriptors 1..6 would always be local to a task. Could this be used in some new and exciting way perhaps? What would the pros and cons be?

[sortie]

So? You tell me what the pros and cons are. Sure it can be done this way but what would the idea be? You are proposing some scheme here, but you need some motivation for it to make any sense.

You do realize that file descriptor table are local to processes in the first place? A process is able to change its file descriptor table it any way it wants using dup2, close and open (to access new file descriptions). File descriptors 0 to INT_MAX (OPEN_MAX, actually) are already local to the current process.

Edit: I also sense some confusion about the difference between file descriptors, file descriptions and the actual files themselves. I don't think you understand this subject at all, actually. Go study some existing implementation!

Edit (again): Also what would happen is that most programs you port will explode because you broke the official semantics of fork and change the file descriptor of stdout.

[NickJohnson]

You can do this manually using dup2. It seems like a sort of strange "optimization", since it makes a semi-common operation slightly easier, and everything else much more annoying. At the very least, you should decouple it from forking.