dce/rpc "client" api

[Cole, Timothy D.]

> -----Original Message-----
> From:	Luke Kenneth Casson Leighton [SMTP:lkcl at samba.org]
> Sent:	Thursday, August 24, 2000 0:38
> To:	Peter Samuelson
> Cc:	Gerald Carter; samba-technical
> Subject:	Re: dce/rpc "client" api
> 
> > In Linux, on the other hand, instead of 10x it's more like 1.5x or so.
> > (Not that threads are *less* efficient -- mostly that fork() is *more*
> > efficient.)  Thus the cost argument for threads doesn't hold up so
> > much.  (But there can still be other reasons!)
> 
> linux processes are a specialisation of threads (or something to that
> effect).
> 
	The Linux kernel doesn't actually have a notion of "processes", as
such.  It's all threads, which may or may not share any combination of
memory, file handles, or assorted other things with their parents.

	e.g. a process is a thread that shares nothing with its parent.

> the same underlying function is used by both create_thread() and fork(),
> and this function is told which of the kernel-bits to copy, and which to
> share.  using a bit-mask :) :)
> 
	It's actually clone() that's used by both (indirectly at the kernel
level by fork(), and directly called by pthread_create() [there is no
create_thread()], which is a glibc function rather than a system call)

	The one downside to this is that it falls to userspace to set up a
new stack for a new thread.

> solaris' fork() function presumably copies _everything_, which is kinda
> majorly expensive.
> 
	Ugh, yeah.  Apparently it does:

	
http://www.sunworld.com/sunworldonline/swol-09-1998/swol-09-insidesolaris_p.
html

	It looks like the overhead for supporting "lightweight processes"
also make fork() even more expensive than it might be otherwise.

	Solaris also has an in-kernel fork() throttle.  fun.

	It looks like the only Unices you can expect copy-on-write forks
from are those derived from BSD 4.4 (where copy-on-write fork() was
apparently first introduced), and Linux.  That basically means none of the
commercial Unices... :/