Messages in this thread | | | Date | Thu, 15 Feb 2007 09:05:13 -0800 (PST) | From | Davide Libenzi <> | Subject | Re: [patch 05/11] syslets: core code |
| |
On Thu, 15 Feb 2007, Linus Torvalds wrote:
> I don't think the "atom" approach is bad per se. I think it could be fine > to have some state information in user space. It's just that I think > complex interfaces that people largely won't even use is a big mistake. We > should concentrate on usability first, and some excessive cleverness > really isn't a big advantage. > > Being able to do a "open + stat" looks like a fine thing. But I doubt > you'll see a lot of other combinations.
I actually think that building chains of syscalls bring you back to a multithreaded solution. Why? Because suddendly the service thread become from servicing a syscall (with possible cachehit optimization), to servicing a whole session. So the number of service threads needed (locked down by a chain) becomes big because requests goes from being short-lived syscalls to long-lived chains of them. Think about the trivial web server, and think about a chain that does open->fstat->sendhdrs->sendfile after an accept. What's the difference with a multithreaded solution that does accept->clone and execute the above code in the new thread? Nada, NIL. Actually, there is a difference. The standard multithreaded function is easier to code in C than with the complex atoms chains. The number of service thread becomes suddendly proportional to the number of active sessions. The more I look at this, the more I think that async_submit should submit simple syscalls, or an array of them (unrelated/parallel).
- Davide
- 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/
| |