dce/rpc "client" api
Cole, Timothy D.
timothy_d_cole at md.northgrum.com
Thu Aug 24 15:36:57 GMT 2000
> -----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
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:
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... :/
More information about the samba-technical