Thread performance (was Re: dynamic context transitions)

[Michael B Allen]

On Sun, 5 Dec 2004 15:40:21 +1100
tridge at samba.org wrote:

> Mike,
> 
> What you've done is made all that memory thread local. So, why are you
> bothering to use threads if you're using thread local memory to make
> it fast?

I don't. I use suba with shared memory. I wasn't really sure if it was
applicable to what you guys are doing. Nevermind :->

>  > It would be much better if the user could create an allocation
>  > context to be used exclusively by the caller thereby eliminating
>  > the need for locks to protect malloc calls. Using my suba
>  > "sub-allocator" module [1] you can initialize an arbitrary chunk of
>  > memory as an allocator:
> 
> and you then need to teach all the internal C library functions to use
> your allocator (think about asprintf). It's all quite possible, but
> all you are achieving is lots of extra code for what you get for free
> by just using damn processes in the first place?

Never been a problem so far and I use suba all over the place. If
libc functions need to use malloc that's fine. And the suba allocator
implementation is very very small (282 lines of code).

> What is it about the word "thread" that people find so damn sexy?

I agree. Unix is designed around the process model. Although if I knew I
didn't need to switch security contexts or serve multiple locales I would
definately have to consider threads as I believe they are a *little*
lighter. For Samba the processes model is clearly the correct choice
(I don't even see how you could *do it* using threads when you can't
call setuid without affecting other threads). Actually I wish rfork /
clone was standard so we could just pick what we want (e.g. can't share
the file table between procs on Solaris).

Mike

-- 
Greedo shoots first? Not in my Star Wars.