Thread performance (was Re: dynamic context transitions)

[tridge at samba.org]

Mike,

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

Really, they aren't lighter. They are in fact _heavier_, as you have
to add extra code for what you get for free in processes (a mmu). Even
if that extra code is small, its not zero.

Back in the dark ages when threads were done in user space then they
could indeed have been thought of as "lighter", but everyone has since
learned the lesson of just how disasterous that approach is, so its
well and truly dead now. Essentially, Linus was right, which shouldn't
be a big surprise to anyone anymore :-)

 > 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).

that's no longer the case. the seteuid() problem has been solved, but
the fcntl locking problem hasn't. See
 http://samba.org/ftp/unpacked/junkcode/pthreads/ 
for some simple test code.

 > Actually I wish rfork / clone was standard

indeed. If we could have pthreads without the library enforced locking
and with control over the clone flags then it would start becoming
useful for file servers.

Cheers, Tridge

PS: for those you you reading this mailing list "thread" and
discovering out of order messages, its because I just told mailman to
accept a bunch of messages that had been blocked due to "too many
recipients". Apologies for the confusion.