Thread performance (was Re: dynamic context transitions)

[tridge at samba.org]

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? The fundamental difference between threads and processes is
that threads by default use shared memory, and processes by default
use non-shared. Thats all that it boils down to.

As I said to Chris, arguments that "threads would be fast if only you
made them more like processes" are pointless. In fact, you are getting
the worst of both worlds, as you get no hardware memory protection
against wild pointers, and you have to have extra code to make all
your memory thread local.

 > The malloc API is pretty stupid if you think about it.

which is why we use talloc in Samba4.

 > 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?

What is it about the word "thread" that people find so damn sexy?
Maybe it needs a name change
"slow-as-hell-no-memory-protection-locks-dont-work" API might be
suitable, but I suspect the standards committees wouldn't like that
one.

The MMU was added to CPUs for a very good reason. Why is it so hard to
understand that trying to avoid it is a bad idea?

Cheers, Tridge