> I would suggest you feed it to Al Viro, as it and also large file arrays
> (expanding the fd arrays on an SMP box is kinda fun 8)) are very much
> related to his vfs threading work and file handle locking.
Would it be worthwhile for me to post my "extended filehandle" proposal
again? I think they solve some of the SMP problems...
struct xfiles_struct {
atomic_t count;
};
To each task add:
struct xfiles_struct *xfiles;
Add CLONE_XFILES. fork() includes CLONE_XFILES. exec() replaces the
task's struct xfiles_struct.
To struct file add:
struct xfiles_struct *owner;
When a task opens an extended filehandle (say O_XFILE, plus some other
trick for socket() and accept()) set the owner appropriately.
Pass back the kernel pointer to the struct file as the "file handle".
OK a bit of massaging here maybe, it could be an index into a global
array. Probably a two level array.
When the kernel is passed an extended file handle it need only verify
that (task->xfiles == file->owner) to ensure the task is permitted to
use the extended file handle.
So at any rate, you can see the problems I'm aiming at solving:
- no need for close_on_exec, it happens automatically by the change of
task->xfiles... really nice for a threaded program with thousands
of open filehandles
- less fancy stuff locking the process's files_struct.
On the other hand, you can probably get much of the SMP benefit by
breaking posix's "must return smallest available fd" semantic.
The tough part is figuring out what form to give extended file handles
back to the user as... I think passing back the kernel pointer is
rad as long as you have some way to ensure they're right on the way
back in :)
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/