Messages in this thread | | | Date | Fri, 8 Jun 2007 22:24:37 +0100 | From | Alan Cox <> | Subject | Re: [patch 7/8] fdmap v2 - implement sys_socket2 |
| |
> > #1: Throw the whole thing away and accept its not a good idea anyway > > Unfortunately (exactly because of the same guarantees you're asking for > those handles), in order for userspace libraries to reliably internally > use fds to interact with the kernel, you need another kind of allocation > strategy.
Unproven and dubious at best as a claim.
> > #2: If I was really going this way and I wanted to use it for serious > > tricks for high performance I/O then I'd provide the handle from > > userspace so that the strategy for allocation is controlled by the caller > > who is the only one who can make the smart decisions > > It does not work. What if the main application, library A and library B > wants to implement their own allocation strategy?
Its called "discipline". I would suggest that libc contains a default allocator. You might also want to assign library and application ranges for clarity.
Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |