On Fri, 9 Feb 2007, Linus Torvalds wrote: > > Another, even simpler way IMO, is to just have a plain per-task kthread > > pool, and a queue. > > Yes, that is actually quite doable with basically the same interface. It's > literally a "small decision" inside of "schedule_async()" on how it > actually would want to handle the case of "hey, we now have concurrent > work to be done".
For the queue approach, I meant the async_submit() to simply add the request (cookie, syscall number and params) inside queue, and not trying to execute the syscall. Once you're inside schedule, "stuff" has already partially happened, and you cannot have the same request re-initiated by a different thread. > But I actually don't think a per-task kthread pool is necessarily a good > idea. If a thread pool works for this, then it should have worked for > regular thread create/destroy loads too - ie there really is little reason > to special-case the "async system call" case. A per-process thread pool already has things correctly inherited, so we don't need to add special "adopt" routines for things like "files" and such. > NOTE! I'm also not at all sure that we actually want to waste real threads > on this. My patch is in no way meant to be an "exclusive alternative" to > fibrils. Quite the reverse, actually: I _like_ those synchronous fibrils, > but I didn't like how Zach did the overhead of creating them up-front, > because I really would like the cached case to be totally *synchronous*. I'm not advocating threads against fibrils. The use of threads may make things easier under certain POVs (less ad-hoc changes into mainline). The ideal would be to have a look at both and see Pros&Cons under different POVs (performance, code impact, etc..). - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/