[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Thread deficiencies



> That one isn't that hard. Setuid() calls aren't all that common, so
> simply making setuid() take the global kernel lock if the credentials
> structure (we would need to move the uid/gid/group information to a
> creds structure) is shared, probably isn't that unreasonable.  

You want to put a conditional, a lock contention, an unlock into every single
syscall path ?  Thats bad enough. Second point. It doesnt work. The lock is 
dropped when you sleep so it doesnt solve your credential problem at all.
Also you've added a pointer indirection to all the uid tests, and used an extra
register in almost every syscall. 

I've actually spent a reasonable amount of time in the past 2 months looking 
at all these issues. The setuid one has no easy solution. It really is more 
efficiently (for the entire system) handled by user space pthread library glue.

>    like with hardware - Linux has to make the fast stuff go very fast
>    and not cripple the fast stuff for broken stuff.
> 
> True, but if our pthreads implementation is far more inefficient than
> the pthreads implementation of other Unices, Linux isn't going to look
> all that good to application writers.  We have to balance that against
> not screwing up the efficiency of the "better" interfaces, and keeping
> the kernel implementation relatively clean, but I think we can do better
> than what we have right now.  

I have yet to see a proposal that solves the uid problem without screwing
the kernel totally. 

> I suspect part of the problem is that most of the kernel developers have
> a very different sense of the importance/priority of getting this
> address than most of the applications developers.

I happen to like the idea of being able to serve several thousand web pages a 
second using rt signal queues and clone. I happen to think that is more
important to Linux as a whole than getting .5% extra throughput out of a 
large proprietary motif monster. Pthreads has never been efficient on any
Unix platform. People writing efficient applications veyr rarely used any
threading or used their own. Sun Java uses its own threads, Netscape servers
use their own threads etc. 

Alan


Reply to: